1. 25 Nov, 2009 1 commit
  2. 24 Nov, 2009 6 commits
  3. 23 Nov, 2009 7 commits
  4. 22 Nov, 2009 1 commit
    • 's avatar
      Bug #48350 truncate temporary table crashes replication · 7f7dabb0
      authored
      In RBR, All statements operating on temporary tables should not be binlogged.
      Despite this fact, after executing 'TRUNCATE... ' on a temporary table, 
      the command is still logged, even if in row-based mode. Consequently, this raises
      problems in the slave as the table may not exist, resulting in an
      execution failure. Ultimately, this causes the slave to report
      an error and abort.
      
      After this patch, 'TRUNCATE ...' statement on a temporary table will not be
      binlogged in RBR.
      7f7dabb0
  5. 21 Nov, 2009 3 commits
  6. 20 Nov, 2009 13 commits
  7. 19 Nov, 2009 2 commits
  8. 18 Nov, 2009 7 commits
    • Georgi Kodinov's avatar
      Bug#48864: MySQL fails to compile on 64 bit Fedora 12 · 6b3b2c0c
      Georgi Kodinov authored
      Fixed 2 errors in comp_err executable : 
      1. Wrong (off by 1) length passed to my_checksum()
      2. strmov() was used on overlapping strings. This is
       not legal according to the docs in stpcpy(). Used 
      the overlap safe memmove() instead.
      6b3b2c0c
    • Sven Sandberg's avatar
      BUG#47995: Mark system functions as unsafe · 349f48e1
      Sven Sandberg authored
      Problem: Some system functions that could return different values on
      master and slave were not marked unsafe. In particular:
       GET_LOCK
       IS_FREE_LOCK
       IS_USED_LOCK
       MASTER_POS_WAIT
       RELEASE_LOCK
       SLEEP
       SYSDATE
       VERSION
      Fix: Mark these functions unsafe.
      349f48e1
    • Jon Olav Hauglid's avatar
      Postfix for Bug #47682 strange behaviour of INSERT DELAYED · 99a4014c
      Jon Olav Hauglid authored
      Fixed a problem with the test case when executed with ps-protocol.
      There the conflicing lock would be noticed during prepare, not
      during execution of the insert - leading to a different (but 
      equally appropriate) error message.
      99a4014c
    • Mattias Jonsson's avatar
      merge · 9e1f4b9b
      Mattias Jonsson authored
      9e1f4b9b
    • Magne Mahre's avatar
      merge · c37250dd
      Magne Mahre authored
      c37250dd
    • Magne Mahre's avatar
      Bug #46425 crash in Diagnostics_area::set_ok_status , empty statement, · 9e6cb377
      Magne Mahre authored
                 DELETE IGNORE
      
      The ER_CANT_UPDATE_USED_TABLE_IN_SF_OR_TRG error was set in the
      diagnostics area when it happened, but the DELETE cleanup code
      never checked for a non-fatal error condition, thus trying to
      set diag.area to "ok".  This triggered an assert checking that
      the diag.area was empty.
      
      The fix was to test if there existed a non-fatal error condition
      (thd->is_error() before ok'ing the operation.
      9e6cb377
    • Jon Olav Hauglid's avatar
      Bug #47682 strange behaviour of INSERT DELAYED · a6733b52
      Jon Olav Hauglid authored
      The problem was a "self-deadlock" if the connection issuing INSERT DELAYED
      had both the global read lock (FLUSH TABLES WITH READ LOCK) and LOCK TABLES
      mode active. The table being inserted into had to be different from the 
      table(s) locked by LOCK TABLES.
      
      For INSERT DELAYED, the connection thread waits until the handler thread has
      opened and locked its table before returning. But since the global read lock
      was active, the handler thread would be unable to lock and would wait for the
      global read lock to go away.
      
      So the handler thread would be waiting for the connection thread to release
      the global read lock while the connection thread was waiting for the handler
      thread to lock the table. This gave a "self-deadlock" (same connection,
      different threads).
      
      The deadlock would only happen if we also had LOCK TABLES mode since the
      INSERT otherwise will try to get protection against global read lock before
      starting the handler thread. It will then notice that the global read lock
      is owned by the same connection and report ER_CANT_UPDATE_WITH_READLOCK.
      
      This patch removes the deadlock by reporting ER_CANT_UPDATE_WITH_READLOCK
      also if we are inside LOCK TABLES mode.
      
      Test case added to delayed.test.
      a6733b52