mirror of
https://github.com/MariaDB/server.git
synced 2025-01-19 05:22:25 +01:00
88a1592b0a
If a conflict happens under wsrep_on, the THD's wsrep_conflict_state is typically set to MUST_ABORT and cleared later, when transaction is aborted. However, when wsrep_on is disabled, no check is performed to see whether wsrep_conflict_state is set. So this potentially creates spurious deadlock errors on the subsequent statement that runs with wsrep_on enabled. To avoid this problem wsrep_thd_set_conflict_state() sets the conflict state only if wsrep_on is enabled.
13 lines
697 B
Text
13 lines
697 B
Text
CREATE TABLE ten (f1 INTEGER);
|
|
INSERT INTO ten VALUES (0),(1),(2),(3),(4),(5),(6),(7),(8),(9);
|
|
CREATE TABLE t1 (f1 INTEGER) Engine=InnoDB;
|
|
INSERT INTO t1 (f1) SELECT 000000 + (10000 * a1.f1) + (1000 * a2.f1) + (100 * a3.f1) + (10 * a4.f1) + a5.f1 FROM ten AS a1, ten AS a2, ten AS a3, ten AS a4, ten AS a5;
|
|
INSERT INTO t1 (f1) SELECT 100000 + (10000 * a1.f1) + (1000 * a2.f1) + (100 * a3.f1) + (10 * a4.f1) + a5.f1 FROM ten AS a1, ten AS a2, ten AS a3, ten AS a4, ten AS a5;;
|
|
SET GLOBAL wsrep_desync = TRUE;
|
|
SET wsrep_on = FALSE;
|
|
ALTER TABLE t1 ADD PRIMARY KEY (f1);
|
|
ERROR 70100: Query execution was interrupted
|
|
SET wsrep_on = TRUE;
|
|
SET GLOBAL wsrep_desync = FALSE;
|
|
DROP TABLE t1;
|
|
DROP TABLE ten;
|