1. 27 Jan, 2010 8 commits
  2. 25 Jan, 2010 3 commits
  3. 22 Jan, 2010 2 commits
  4. 21 Jan, 2010 3 commits
  5. 20 Jan, 2010 4 commits
  6. 19 Jan, 2010 9 commits
  7. 18 Jan, 2010 8 commits
  8. 17 Jan, 2010 1 commit
  9. 16 Jan, 2010 1 commit
    • 's avatar
      BUG#47418 RBR fails, failure with mixup of base/temporary/view · 6f380d16
      authored
      'CREATE TABLE IF NOT EXISTS ... SELECT' statement were causing 'CREATE
      TEMPORARY TABLE ...' to be written to the binary log in row-based 
      mode (a.k.a. RBR), when there was a temporary table with the same name.
      Because the 'CREATE TABLE ... SELECT' statement was executed as 
      'INSERT ... SELECT' into the temporary table. Since in RBR mode no 
      other statements related to temporary tables are written into binary log,
      this sometimes broke replication.
      
      This patch changes behavior of 'CREATE TABLE [IF NOT EXISTS] ... SELECT ...'.
      it ignores existence of temporary table with the 
      same name as table being created and is interpreted
      as attempt to create/insert into base table. This makes behavior of
      'CREATE TABLE [IF NOT EXISTS] ... SELECT' consistent with
      how ordinary 'CREATE TABLE' and 'CREATE TABLE ... LIKE' behave.
      6f380d16
  10. 15 Jan, 2010 1 commit
    • Georgi Kodinov's avatar
      Bug #46175: NULL read_view and consistent read assertion · 440f5a9c
      Georgi Kodinov authored
      The optimizer must not continue executing the current query
      if e.g. the storage engine reports an error.
      This is somewhat hard to implement with Item::val_xxx()
      because they do not have means to return error code.
      This is why we need to check the thread's error state after
      a call to one of the Item::val_xxx() methods.
      
      Fixed store_key_item::copy_inner() to return an error state 
      if an error happened during the call to Item::save_in_field() 
      because it calls Item::val_xxx().
      Also added similar checks to related places.
      440f5a9c