mirror of
https://github.com/MariaDB/server.git
synced 2025-01-18 04:53:01 +01:00
352ad8156c
(originally reported as "second run of innobackup hangs forever and can even hang server"). Plus testcase for the bugfix and comments about global read locks. mysql-test/r/flush_block_commit.result: result update mysql-test/t/flush_block_commit.test: testing bugfix (originally: second run of innobackup hangs) sql/lock.cc: When we are in start_waiting_global_read_lock(), if we ourselves have the global read lock, there is nothing to start. This makes a pair with how wait_if_global_read_lock() behaves when we ourselves have the global read lock. Previously, start_waiting_global_read_lock() decremented protect... whereas wait_if_global_read_lock() hadn't incremented it => very wrong => hangs. Descriptive comments on how global read lock works.
63 lines
1.3 KiB
Text
63 lines
1.3 KiB
Text
# Let's see if FLUSH TABLES WITH READ LOCK blocks COMMIT of existing
|
|
# transactions.
|
|
# We verify that we did not introduce a deadlock.
|
|
|
|
-- source include/have_innodb.inc
|
|
|
|
connect (con1,localhost,root,,);
|
|
connect (con2,localhost,root,,);
|
|
connect (con3,localhost,root,,);
|
|
connection con1;
|
|
drop table if exists t1;
|
|
create table t1 (a int) type=innodb;
|
|
|
|
# blocks COMMIT ?
|
|
|
|
begin;
|
|
insert into t1 values(1);
|
|
connection con2;
|
|
flush tables with read lock;
|
|
select * from t1;
|
|
connection con1;
|
|
send commit; # blocked by con2
|
|
sleep 1;
|
|
connection con2;
|
|
select * from t1; # verify con1 was blocked and data did not move
|
|
unlock tables;
|
|
connection con1;
|
|
reap;
|
|
|
|
# No deadlock ?
|
|
|
|
connection con1;
|
|
begin;
|
|
select * from t1 for update;
|
|
connection con2;
|
|
begin;
|
|
send select * from t1 for update; # blocked by con1
|
|
sleep 1;
|
|
connection con3;
|
|
send flush tables with read lock; # blocked by con2
|
|
connection con1;
|
|
commit; # should not be blocked by con3
|
|
connection con2;
|
|
reap;
|
|
connection con3;
|
|
reap;
|
|
unlock tables;
|
|
|
|
# BUG#6732 FLUSH TABLES WITH READ LOCK + COMMIT hangs later FLUSH TABLES
|
|
# WITH READ LOCK
|
|
|
|
connection con2;
|
|
commit; # unlock InnoDB row locks to allow insertions
|
|
connection con1;
|
|
begin;
|
|
insert into t1 values(10);
|
|
flush tables with read lock;
|
|
commit;
|
|
unlock tables;
|
|
connection con2;
|
|
flush tables with read lock; # bug caused hang here
|
|
unlock tables;
|
|
drop table t1;
|