mirror of
https://github.com/MariaDB/server.git
synced 2026-02-24 03:28:46 +01:00
Fix sporadic failure for MTR test galera_sr.GCF-1018B. The test sometimes fails due to an error that is logged to the error log unnecessarily. A deterministic test case (included in this patch) shows that the error is loggen when a transaction is BF aborted right before it opens the streaming log table to perform fragment removal. When that happens, the attempt to open the table fails and consequently an error is logged. There is no need to log this error, as an ER_LOCK_DEADLOCK error is returned to the client. Reviewed-by: Jan Lindström <jan.lindstrom@mariadb.com>
36 lines
930 B
Text
36 lines
930 B
Text
#
|
|
# MDEV-21613 - galera_sr.GCF-1018B MTR failed:
|
|
# Failed to open table mysql.wsrep_streaming_log for writing
|
|
#
|
|
# A BF abort right before fragment removal caused this error to
|
|
# be logged to the error log.
|
|
#
|
|
--source include/galera_cluster.inc
|
|
--source include/have_debug_sync.inc
|
|
|
|
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY);
|
|
|
|
--connection node_1
|
|
SET SESSION wsrep_trx_fragment_size = 1;
|
|
SET DEBUG_SYNC = "wsrep_before_fragment_removal SIGNAL fragment_removal_reached WAIT_FOR fragment_removal_continue";
|
|
START TRANSACTION;
|
|
INSERT INTO t1 VALUES(1), (2);
|
|
--send COMMIT
|
|
|
|
--connect node_ctrl, 127.0.0.1, root, , test, $NODE_MYPORT_1
|
|
--connection node_ctrl
|
|
SET DEBUG_SYNC = "now WAIT_FOR fragment_removal_reached";
|
|
|
|
|
|
--connect node_1a, 127.0.0.1, root, , test, $NODE_MYPORT_1
|
|
--connection node_1a
|
|
TRUNCATE TABLE t1;
|
|
|
|
|
|
--connection node_1
|
|
--error ER_LOCK_DEADLOCK
|
|
--reap
|
|
|
|
--connection node_ctrl
|
|
SET DEBUG_SYNC = 'RESET';
|
|
DROP TABLE t1;
|