#At file:///home/sven/bzr/b12574820-reset_logs_lock_order/5.1/ based on revid:vasil.dimov@stripped
3625 Sven Sandberg 2011-05-23
BUG#12574820: binlog.binlog_tmp_table timing out in daily and weekly trunk run
Problem: MYSQL_BIN_LOG::reset_logs acquires mutexes in wrong order.
The correct order is first LOCK_thread_count and then LOCK_log. This function
does it the other way around. This leads to deadlock when run in parallel
with a thread that takes the two locks in correct order. For example, a thread
that disconnects will take the locks in the correct order.
Fix: change order of the locks in MYSQL_BIN_LOG::reset_logs:
first LOCK_thread_count and then LOCK_log.
It is not possible to create a deterministic test case where RESET MASTER
deadlocks with a thread that is disconnecting: that would require a debug_sync
point, but the debug_sync feature shuts down for the disconnecting thread
before it acquires LOCK_thread_count.
Change mutex acquisition to the correct order:
first LOCK_thread_count, then LOCK_log.
=== modified file 'sql/log.cc'
--- a/sql/log.cc 2011-02-22 21:03:32 +0000
+++ b/sql/log.cc 2011-05-23 15:28:50 +0000
@@ -2989,12 +2989,6 @@ bool MYSQL_BIN_LOG::reset_logs(THD* thd)
- We need to get both locks to be sure that no one is trying to
- write to the index log file.
The following mutex is needed to ensure that no threads call
@@ -3002,7 +2996,14 @@ bool MYSQL_BIN_LOG::reset_logs(THD* thd)
thread. If the transaction involved MyISAM tables, it should go
into binlog even on rollback.
+ We need to get both locks to be sure that no one is trying to
+ write to the index log file.
/* Save variables so that we can reopen the log */
Attachment: [text/bzr-bundle] email@example.com
|• bzr commit into mysql-5.1 branch (sven.sandberg:3625) Bug#12574820||Sven Sandberg||23 May|