1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix bug #11934 Two sequential FLUSH TABLES WITH READ LOCK hangs client

Browse Source 
Bug was introduced by cset 1.1659.14.1. Before it server was silently
ignoring that lock can't be acquired because it already acquired.

This patch makes make_global_read_lock_block_commit() return without error
if lock already acquired.
This commit is contained in:
evgen@moonbone.local 2005-08-03 02:01:27 +04:00
parent 655a86a9e7
commit 706247caae
3 changed files with 11 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
mysql-test/r/flush_table.result
View File

@ -101,3 +101,6 @@ table_id
Record-02
handler t1 close;
drop table t1;
FLUSH TABLES WITH READ LOCK ;
FLUSH TABLES WITH READ LOCK ;
UNLOCK TABLES;

7
mysql-test/t/flush_table.test
View File

@ -73,4 +73,11 @@ handler t1 read next limit 1;
handler t1 close;
drop table t1;
#
# Bug #11934 Two sequential FLUSH TABLES WITH READ LOCK hangs client
#
FLUSH TABLES WITH READ LOCK ;
FLUSH TABLES WITH READ LOCK ;
UNLOCK TABLES;
# End of 4.1 tests

2
sql/lock.cc
View File

@ -990,7 +990,7 @@ bool make_global_read_lock_block_commit(THD *thd)
make_global_read_lock_block_commit(), do nothing.
*/
if (thd->global_read_lock != GOT_GLOBAL_READ_LOCK)
DBUG_RETURN(1);
DBUG_RETURN(0);
pthread_mutex_lock(&LOCK_global_read_lock);
/* increment this BEFORE waiting on cond (otherwise race cond) */
global_read_lock_blocks_commit++;