1. 09 Apr, 2009 1 commit
    • He Zhenxing's avatar
      Post fix of BUG#37145 · 41361d89
      He Zhenxing authored
      Binlog the CREATE EVENT unless the created event been successfully dropped
      
      Modified Query_log_event constructor to make sure that error_code
      is not set to ER_SERVER_SHUTDOWN or ER_QUERY_INTERRUPTED errors
      when NOT_KILLED
      41361d89
  2. 08 Apr, 2009 4 commits
  3. 07 Apr, 2009 5 commits
  4. 06 Apr, 2009 2 commits
  5. 03 Apr, 2009 6 commits
    • Serge Kozlov's avatar
      Bug#37716. · 2ee7a7cf
      Serge Kozlov authored
      1. Test case was rewritten completely.
      2. Test covers 3 cases:
       a) do deadlock on slave, wait retries of transaction, unlock slave before lock
      timeout;
       b) do deadlock on slave and wait error 'lock timeout exceed' on slave;
       c) same as b) but if of max relay log size = 0;
      3. Added comments inline.
      4. Updated result file.
      2ee7a7cf
    • Davi Arnaut's avatar
      Merge Bug#43230 into mysql-5.1-bugteam · ec762cbd
      Davi Arnaut authored
      ec762cbd
    • Davi Arnaut's avatar
      Bug#43230: SELECT ... FOR UPDATE can hang with FLUSH TABLES WITH READ LOCK indefinitely · aebaf079
      Davi Arnaut authored
      The problem is that a SELECT .. FOR UPDATE statement might open
      a table and later wait for a impeding global read lock without
      noticing whether it is holding a table that is being waited upon
      the the flush phase of the process that took the global read
      lock.
      
      The same problem also affected the following statements:
      
      LOCK TABLES .. WRITE
      UPDATE .. SET (update and multi-table update)
      TRUNCATE TABLE ..
      LOAD DATA ..
      
      The solution is to make the above statements wait for a impending
      global read lock before opening the tables. If there is no
      impending global read lock, the statement raises a temporary
      protection against global read locks and progresses smoothly
      towards completion.
      
      Important notice: the patch does not try to address all possible
      cases, only those which are common and can be fixed unintrusively
      enough for 5.0.
      aebaf079
    • Guangbao Ni's avatar
      AutoMerged from pushbuild mysql-5.1-bugteam · 48f43531
      Guangbao Ni authored
      48f43531
    • Guangbao Ni's avatar
      BUG#42640 mysqld crashes when unsafe statements are executed (STRICT_TRANS_TABLESmode) · 61ce7092
      Guangbao Ni authored
      Mysql server crashes because unsafe statements warning is wrongly elevated to error,
      which is set the error status of Diagnostics_area of the thread in THD::binlog_query().
      Yet the caller believes that binary logging shouldn't touch the status, so it will
      set the status also later by my_ok(), my_error() or my_message() seperately
      according to the execution result of the statement or transaction.
      But the status of Diagnostics_area of the thread is allowed to set only once.
      
      Fixed to clear the error wrongly set by binary logging, but keep the warning message.
      61ce7092
    • Horst Hunger's avatar
      Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some... · 33364242
      Horst Hunger authored
      Fix belonging to bug#42838: Though this bug is only for 6.0 I put in some updated result files for 6.0 and this are the corrsponding resul files for 5.1, so that sys_vars should then run successfully also in 5.1.
      33364242
  6. 02 Apr, 2009 10 commits
  7. 01 Apr, 2009 12 commits