1. 14 Oct, 2010 1 commit
    • Davi Arnaut's avatar
      Bug#56096: STOP SLAVE hangs if executed in parallel with user sleep · 7d64c364
      Davi Arnaut authored
      The root of the problem is that to interrupt a slave SQL thread
      wait, the STOP SLAVE implementation uses thd->awake(THD::NOT_KILLED).
      This appears as a spurious wakeup (e.g. from a sleep on a
      condition variable) to the code that the slave SQL thread is
      executing at the time of the STOP. If the code is not written
      to be spurious-wakeup safe, unexpected behavior can occur. For
      the reported case, this problem led to an infinite loop around
      the interruptible_wait() function in item_func.cc (SLEEP()
      function implementation).  The loop was not being properly
      restarted and, consequently, would not come to an end. Since the
      SLEEP function sleeps on a timed event in order to be killable
      and to perform periodic checks until the requested time has
      elapsed, the spurious wake up was causing the requested sleep
      time to be reset every two seconds.
      
      The solution is to calculate the requested absolute time only
      once and to ensure that the thread only sleeps until this
      time is elapsed. In case of a spurious wake up, the sleep is
      restarted using the previously calculated absolute time. This
      restores the behavior present in previous releases. If a slave
      thread is executing a SLEEP function, a STOP SLAVE statement
      will wait until the time requested in the sleep function
      has elapsed.
      7d64c364
  2. 13 Oct, 2010 8 commits
  3. 12 Oct, 2010 3 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 13 commits