| Bug #10942 | deadlock with FLUSH TABLES WITH READ LOCK + STOP SLAVE | ||
|---|---|---|---|
| Submitted: | 29 May 2005 12:42 | Modified: | 9 Dec 2005 18:52 |
| Reporter: | Guilhem Bichot | Email Updates: | |
| Status: | Closed | Impact on me: | |
| Category: | MySQL Server: Replication | Severity: | S3 (Non-critical) |
| Version: | 4.1 | OS: | Linux (linux) |
| Assigned to: | Sergei Golubchik | CPU Architecture: | Any |
[8 Oct 2005 16:41]
Sergei Golubchik
fixed in 4.1.16 and 5.0.15
[9 Oct 2005 6:57]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/internals/30838
[9 Dec 2005 18:52]
Paul DuBois
Noted in 4.1.16, 5.0.15 changelogs.
Description: Probably happens with 4.0 and 5.0 too. If a client thread on slave does FLUSH TABLES WITH READ LOCK; it will prevent slave SQL thread to start next replicated statement. Then if the same client thread does STOP SLAVE, it will wait for the slave SQL thread to die but this thread is waiting for the global read lock to be gone, in order to execute its statement and _then_ die. So it's a deadlock: SLAVE> show processlist; +----+-------------+-----------+------+---------+------+---------------------------------+---------------------+ | Id | User | Host | db | Command | Time | State | Info | +----+-------------+-----------+------+---------+------+---------------------------------+---------------------+ | 4 | root | localhost | NULL | Query | 3 | Killing slave | stop slave | | 6 | root | localhost | NULL | Query | 0 | NULL | show processlist | | 8 | system user | | db1 | Connect | 47 | Waiting for release of readlock | create database db1 | +----+-------------+-----------+------+---------+------+---------------------------------+---------------------+ How to repeat: Set up replication. slave: STOP SLAVE; master: CREATE DATABASE db1; slave: FLUSH TABLES WITH READ LOCK; slave: START SLAVE; # slave SQL thread will block slave: STOP SLAVE; Suggested fix: Extend this check in sql_parse.cc: case SQLCOM_SLAVE_STOP: if (thd->locked_tables || thd->active_transaction()) { send_error(thd,ER_LOCK_OR_ACTIVE_TRANSACTION); break; } by adding a "|| thd->global_read_lock" in the if().