MySQL Bugs: #2397: RENAME TABLES is not blocked by FLUSH TABLES WITH READ LOCK

Bug #2397	RENAME TABLES is not blocked by FLUSH TABLES WITH READ LOCK
Submitted:	15 Jan 2004 4:40	Modified:	2 Apr 2004 10:00
Reporter:	Guilhem Bichot	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	4.1	OS:	Any (all)
Assigned to:	Bugs System	CPU Architecture:	Any

Description:
Can be seen from the code, and also by testing:
do FLUSH TABLES WITH READ LOCK;
and in another connection do
RENAME TABLE t TO u;
RENAME succeeds immediately instead of waiting
This is a problem if you are using FLUSH TABLES WITH READ LOCK to do a consistent backup, like mysqlhotcopy or innobackup do.

How to repeat:
see description.

Suggested fix:
As the older bug "CREATE TABLE is not blocked by FLUSH TABLES WITH READ LOCK" was fixed in 4.1, I guess this should be fixed in 4.1?

I forgot to say I tested the bug with 4.1, so it's not already fixed.

subj: bk commit - 4.1 tree (vva:1.1746) BUG#2397

ChangeSet
  1.1746 04/04/01 22:47:09 vva@eagle.mysql.r18.ru +3 -0
  fixed 
  BUG #2397 "RENAME TABLES is not blocked by FLUSH TABLES WITH READ LOCK"
  (added waiting for global_read_lock in mysql_rename_tables)

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 bugfix, yourself. More information 
about accessing the source trees is available at
    http://www.mysql.com/doc/en/Installing_source_tree.html

Additional info:

The fix will be in the mysql-4.1.2