MySQL Bugs: #26380: LOCK TABLES + FLUSH LOGS causes deadlock

Bug #26380	LOCK TABLES + FLUSH LOGS causes deadlock
Submitted:	14 Feb 2007 20:28	Modified:	23 Jun 2007 8:31
Reporter:	Sarah Sproehnle	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server: Locking	Severity:	S2 (Serious)
Version:	5.1.14-beta	OS:	Any (Windows XP)
Assigned to:	Ramil Kalimullin	CPU Architecture:	Any

Description:
"FLUSH TABLES WITH READ LOCK; FLUSH LOGS;" causes deadlock if the general_log or slow_query_log are on.

How to repeat:
SET GLOBAL general_log=ON;
FLUSH TABLES WITH READ LOCK;
FLUSH TABLES;  --hangs

Sorry, that was supposed to be:
FLUSH TABLES WITH READ LOCK;
FLUSH LOGS; --hangs

Thank you for the report.

Verified as described.

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/commits/27764

ChangeSet@1.2526, 2007-05-31 12:48:10+05:00, ramil@mysql.com +3 -0
  Fix for bug #26380: LOCK TABLES + FLUSH LOGS causes deadlock
  
  Problem: executing 'flush logs' we don't check global read lock for a thread 
  launching the command. That may cause a deadlock if tables are locked
  and logger calls wait_if_global_read_lock() for the logging thread
  that is not the owner of the global read lock.
  
  Fix: check for global read lock before flushing logs.

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/commits/28869

ChangeSet@1.2497, 2007-06-15 19:11:10+05:00, ramil@mysql.com +5 -0
  Fix for bug #26380: LOCK TABLES + FLUSH LOGS causes deadlock
  
  Problem: flushing logs we may hit a deadlock if the GLOBAL READ LOCK was 
  accuired before, as the logger calls wait_if_global_read_lock() for the 
  logging thread that is not an owner of the GLOBAL READ LOCK.
  Fix: the logger shouldn't honor the GLOBAL READ LOCK flushing its tables.

Patch approved.

Sent comments by email, with suggestion for the change set comments.

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/commits/28937

ChangeSet@1.2502, 2007-06-17 09:56:33+05:00, ramil@mysql.com +5 -0
  Fix for bug #26380: LOCK TABLES + FLUSH LOGS causes deadlock
  
  The log tables are by nature PERFORMANCE_SCHEMA tables,
  which should not be affected by SET GLOBAL READ_ONLY or FLUSH TABLES
  WITH READ LOCK.
  
  The implementation of FLUSH TABLES WITH READ LOCK already ignored log tables.
  Now with this patch, the implementation of LOCK TABLE also ignore a
  global read lock for log tables, which was the missing symmetry.

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/commits/29017

ChangeSet@1.2505, 2007-06-18 22:22:31+05:00, ramil@mysql.com +3 -0
  Sdditional fix-up for bug #26380: LOCK TABLES + FLUSH LOGS causes deadlock
  
  FLUSH LOGS should ignore SET GLOBAL READ_ONLY.

Pushed into 5.1.20-beta

Thank you for your bug report. This issue has been committed to our source repository of that product and will be incorporated into the next release.

If necessary, you can access the source repository and build the latest available version, including the bug fix. More information about accessing the source trees is available at

    http://dev.mysql.com/doc/en/installing-source.html

Documented bugfix in the 5.1.20 as follows:

A <literal>FLUSH TABLES WITH READ LOCK</literal> statement followed by a
          <literal>FLUSH LOGS</literal> statement caused a deadlock if the general
          log or the slow query log was enabled.