1. 14 Oct, 2010 2 commits
  2. 13 Oct, 2010 3 commits
    • Jon Olav Hauglid's avatar
      Bug #55930 Assertion `thd->transaction.stmt.is_empty() || · 4eb32469
      Jon Olav Hauglid authored
                 thd->in_sub_stmt || (thd->state..
      
      OPTIMIZE TABLE is not directly supported by InnoDB. Instead,
      recreate and analyze of the table is done. After recreate,
      the table is closed and locks are released before the table
      is reopened and locks re-acquired for the analyze phase.
      
      This assertion was triggered if OPTIMIZE TABLE failed to
      acquire thr_lock locks before starting the analyze phase.
      The assertion tests (among other things) that there no
      active statement transaction. However, as part of acquiring
      the thr_lock lock, external_lock() is called for InnoDB
      tables and this causes a statement transaction to be started.
      If thr_multi_lock() later fails (e.g. due to timeout),
      the failure handling code causes this assert to be triggered.
      
      This patch fixes the problem by doing rollback of the
      current statement transaction in case open_ltable (used by
      OPTIMIZE TABLE) fails to acquire thr_lock locks.
      
      Test case added to lock_sync.test.
      4eb32469
    • Dmitry Lenev's avatar
      Fix for bug #57422 "rpl_row_sp003 sporadically fails under · 8007ef52
      Dmitry Lenev authored
      heavy load".
      
      rpl_row_sp003.test has sporadically failed when run on machine
      under heavy load or on slow hardware.
      
      This patch fixes races in the test which were causing these
      failures and also removes unnecessary 100 second wait from it. 
      8007ef52
    • Konstantin Osipov's avatar
  3. 12 Oct, 2010 4 commits
  4. 11 Oct, 2010 11 commits
  5. 10 Oct, 2010 2 commits
  6. 09 Oct, 2010 2 commits
    • 's avatar
      Manual merge · a667ce8e
      authored
      a667ce8e
    • 's avatar
      Bug#55375 Transaction bigger than max_binlog_cache_size crashes slave · b6682591
      authored
      When slave executes a transaction bigger than slave's max_binlog_cache_size,
      slave will crash. It is caused by the assert that server should only roll back
      the statement but not the whole transaction if the error ER_TRANS_CACHE_FULL 
      happens. But slave sql thread always rollbacks the whole transaction when
      an error happens.
                  
      Ather this patch, we always clear any error set in sql thread(it is different
      from the error in 'SHOW SLAVE STATUS') and it is cleared before rolling back
      the transaction.
      b6682591
  7. 08 Oct, 2010 15 commits
  8. 07 Oct, 2010 1 commit