mirror of
https://github.com/MariaDB/server.git
synced 2025-01-17 20:42:30 +01:00
5792c4d162
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. mysql-test/t/flush_table.test: Test case for bug#11934 FLUSH TABLES WITH READ LOCK hangs client. mysql-test/r/flush_table.result: Test case for bug#11934 FLUSH TABLES WITH READ LOCK hangs client. sql/lock.cc: Fix bug #11934 Two sequential FLUSH TABLES WITH READ LOCK hangs client. Make make_global_read_lock_block_commit() return without error if lock already acquired.
83 lines
2 KiB
Text
83 lines
2 KiB
Text
# TODO: Only run this if we have privilege to do flush table
|
|
|
|
#
|
|
# Test of flush table
|
|
#
|
|
|
|
--disable_warnings
|
|
drop table if exists t1,t2;
|
|
--enable_warnings
|
|
create table t1 (a int not null auto_increment primary key);
|
|
insert into t1 values(0);
|
|
lock table t1 read;
|
|
flush table t1;
|
|
check table t1;
|
|
drop table t1;
|
|
|
|
#
|
|
# In the following test FLUSH TABLES produces a deadlock
|
|
# (hang forever) if the fix for BUG #3565 is missing.
|
|
# And it shows that handler tables are re-opened after flush (BUG #4286).
|
|
#
|
|
create table t1(table_id char(20) primary key);
|
|
create table t2(table_id char(20) primary key);
|
|
insert into t1 values ('test.t1');
|
|
insert into t1 values ('');
|
|
insert into t2 values ('test.t2');
|
|
insert into t2 values ('');
|
|
handler t1 open as a1;
|
|
handler t1 open as a2;
|
|
handler t2 open;
|
|
handler a1 read first limit 9;
|
|
handler a2 read first limit 9;
|
|
handler t2 read first limit 9;
|
|
flush tables;
|
|
handler a1 read first limit 9;
|
|
handler a2 read first limit 9;
|
|
handler t2 read first limit 9;
|
|
#
|
|
--error 1066
|
|
handler t1 open as a1;
|
|
--error 1066
|
|
handler t1 open as a2;
|
|
--error 1066
|
|
handler t2 open;
|
|
handler a1 read first limit 9;
|
|
handler a2 read first limit 9;
|
|
handler t2 read first limit 9;
|
|
flush table t1;
|
|
handler a1 read first limit 9;
|
|
handler a2 read first limit 9;
|
|
handler t2 read first limit 9;
|
|
flush table t2;
|
|
handler t2 close;
|
|
drop table t1;
|
|
drop table t2;
|
|
|
|
#
|
|
# The fix for BUG #4286 cannot restore the position after a flush.
|
|
#
|
|
create table t1(table_id char(20) primary key);
|
|
insert into t1 values ('Record-01');
|
|
insert into t1 values ('Record-02');
|
|
insert into t1 values ('Record-03');
|
|
insert into t1 values ('Record-04');
|
|
insert into t1 values ('Record-05');
|
|
handler t1 open;
|
|
handler t1 read first limit 1;
|
|
handler t1 read next limit 1;
|
|
handler t1 read next limit 1;
|
|
flush table t1;
|
|
handler t1 read next limit 1;
|
|
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
|