1
0
mirror of https://github.com/MariaDB/server.git synced 2025-11-28 17:36:30 +03:00
Files
mariadb/mysql-test/suite/stress/t/deadlock_drop_table.test
Monty 93f5d40656 Fixed debug_sync timeout in deadlock_drop_table
The issue was that we sent two different signals to different threads
after each other. The DEBUG_SYNC functionality cannot handle this (as
the signal is stored in a global variable) and the first one can get
lost.

Fixed by using the same signal for both threads.
2021-06-19 03:46:00 +03:00

40 lines
1.1 KiB
Plaintext

--source include/have_debug.inc
create or replace table t1 (a int primary key, b int, c int, key(b),key(c)) engine=myisam;
insert into t1 (a) values(1);
set debug_sync='RESET';
connect (con1, localhost, root,,);
connect (con2, localhost, root,,);
connection default;
backup stage start;
backup stage flush;
select * from t1;
set debug_sync='after_purge_tables SIGNAL parked WAIT_FOR go';
set debug_sync='before_tc_release_table SIGNAL parked2 WAIT_FOR go2';
--send backup stage BLOCK_DDL
--connection con1
set debug_sync='now WAIT_FOR parked';
select * from t1;
set debug_sync='now SIGNAL go';
set debug_sync='now WAIT_FOR parked2';
set debug_sync='before_wait_for_refs SIGNAL waiting WAIT_FOR go2';
--send drop table t1;
--connection con2
set debug_sync='now WAIT_FOR waiting';
set debug_sync='now SIGNAL go2';
# Write out show processlist if the debug sync point times out
let $wait_condition= select count(*)=0 from information_schema.processlist where state like "%debug%";
source include/wait_condition.inc;
--connection default
--reap
--connection con1
--reap
connection default;
disconnect con1;
disconnect con2;
set debug_sync='RESET';