1berry/MariaDB-server
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

MDEV-33136: Properly BF-abort user transactions with explicit locks

Browse Source 
User transactions may acquire explicit MDL locks from InnoDB level
when persistent statistics is re-read for a table.
If such a transaction would be subject to BF-abort, it was improperly
detected as a system transaction and wouldn't get aborted.

The fix: Check if a transaction holding explicit MDL locks is a user
transaction in the MDL conflict handling code.

Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
This commit is contained in:
Denis Protivensky 2024-02-06 11:55:04 +03:00 committed by Julius Goryavsky
parent 318000cffc
commit 7bf3c3124a
4 changed files with 72 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
mysql-test/suite/galera/r/MDEV-33136.result Normal file
View File

@ -0,0 +1,21 @@
connection node_2;
connection node_1;
connect node_1a,127.0.0.1,root,,test,$NODE_MYPORT_1;
connection node_1;
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) ENGINE=InnoDB;
connection node_1a;
TRUNCATE TABLE t1;
SET SESSION wsrep_retry_autocommit = 0;
SET DEBUG_SYNC = 'dict_stats_mdl_acquired SIGNAL may_toi WAIT_FOR bf_abort';
INSERT INTO t1 VALUES (1);
connection node_1;
SET DEBUG_SYNC = 'now WAIT_FOR may_toi';
TRUNCATE TABLE t1;
connection node_1a;
ERROR 40001: Deadlock found when trying to get lock; try restarting transaction
connection node_1;
SET DEBUG_SYNC = 'RESET';
DROP TABLE t1;
disconnect node_1a;
disconnect node_2;
disconnect node_1;

44
mysql-test/suite/galera/t/MDEV-33136.test Normal file
View File

@ -0,0 +1,44 @@
#
# MDEV-33136: Properly BF-abort user transactions with explicit locks
#
# User transactions may acquire explicit MDL locks from InnoDB level
# when persistent statistics is re-read for a table.
# If such a transaction would be subject to BF-abort, it was improperly
# detected as a system transaction and wouldn't get aborted.
#
# The fix: Check if a transaction holding explicit MDL locks is a user
# transaction in the MDL conflict handling code.
--source include/galera_cluster.inc
--source include/have_debug_sync.inc
--source include/have_debug.inc
--connect node_1a,127.0.0.1,root,,test,$NODE_MYPORT_1
--connection node_1
CREATE TABLE t1 (f1 INTEGER PRIMARY KEY) ENGINE=InnoDB;
--connection node_1a
TRUNCATE TABLE t1;
# TRUNCATE forces the next statement to re-read statistics from persistent storage,
# which will acquire MDL locks on the statistics tables in InnoDB.
SET SESSION wsrep_retry_autocommit = 0;
SET DEBUG_SYNC = 'dict_stats_mdl_acquired SIGNAL may_toi WAIT_FOR bf_abort';
--send
INSERT INTO t1 VALUES (1);
--connection node_1
SET DEBUG_SYNC = 'now WAIT_FOR may_toi';
TRUNCATE TABLE t1;
--connection node_1a
# Local INSERT gets aborted.
--error ER_LOCK_DEADLOCK
--reap
# Cleanup
--connection node_1
SET DEBUG_SYNC = 'RESET';
DROP TABLE t1;
--disconnect node_1a
--source include/galera_end.inc

4
sql/wsrep_mysqld.cc
View File

@ -3168,7 +3168,9 @@ void wsrep_handle_mdl_conflict(MDL_context *requestor_ctx,
}
}
else if (granted_thd->lex->sql_command == SQLCOM_FLUSH ||
granted_thd->mdl_context.has_explicit_locks())
/* System transactions with explicit locks are BACKUP. */
(granted_thd->system_thread != NON_SYSTEM_THREAD &&
granted_thd->mdl_context.has_explicit_locks()))
{
WSREP_DEBUG("BF thread waiting for FLUSH");
ticket->wsrep_report(wsrep_debug);

4
storage/innobase/dict/dict0stats.cc
View File

@ -3865,6 +3865,10 @@ release_and_exit:
goto release_and_exit;
}
#ifdef ENABLED_DEBUG_SYNC
DEBUG_SYNC(thd, "dict_stats_mdl_acquired");
#endif /* ENABLED_DEBUG_SYNC */
trx = trx_create();
trx_start_internal_read_only(trx);