mirror of
https://github.com/MariaDB/server.git
synced 2025-01-17 04:22:27 +01:00
8e63a7fe27
I think I finally found the problem, managed to reproduce locally using a sleep in the test case to simulate the particular race condition that causes the test to fail often in Buildbot. The test starts an ALTER TABLE that does repair by sort in one thread, then another thread waits for the sort to be visible in SHOW PROCESSLIST and runs a SHOW statement in parallel. The problem happens when the sort manages to run to completion before the other thread has the time to look at SHOW PROCESSLIST. In this case, the wait times out because the state looked for has already passed. Earlier I added some DEBUG_SYNC to prevent this race, but it turns out that DEBUG_SYNC itself changes the state in the processlist. So when the debug sync point was hit, the processlist was showing the wrong state, so the wait would still time out. Fixed now by looking for the processlist to contain either the "Repair by sorting" state or the debug sync wait stage. Also clean up previous attempts to fix it. Set the wait timeout back to reasonable 60 seconds, and simplify the DEBUG_SYNC operations to work closer to how the original test case was intended.
15 lines
591 B
Text
15 lines
591 B
Text
DROP TABLE IF EXISTS t1;
|
|
CREATE TABLE t1 (
|
|
id INT PRIMARY KEY,
|
|
a VARCHAR(100),
|
|
INDEX(a)
|
|
) ENGINE=MyISAM;
|
|
ALTER TABLE t1 DISABLE KEYS;
|
|
SET debug_sync= 'myisam_after_repair_by_sort WAIT_FOR go';
|
|
ALTER TABLE t1 ENABLE KEYS;
|
|
SET debug_sync= 'now SIGNAL go';
|
|
SHOW TABLE STATUS LIKE 't1';
|
|
Name Engine Version Row_format Rows Avg_row_length Data_length Max_data_length Index_length Data_free Auto_increment Create_time Update_time Check_time Collation Checksum Create_options Comment
|
|
t1 MyISAM 10 Dynamic 100000 27 # # # 0 NULL # # # latin1_swedish_ci NULL
|
|
DROP TABLE t1;
|
|
set debug_sync='reset';
|