mirror of
https://github.com/MariaDB/server.git
synced 2025-02-12 00:15:35 +01:00
841a7d391b
DROP TABLE on child and UPDATE of parent table can cause an MDL BF-BF conflict when applied concurrently. DROP TABLE takes MDL locks on both child and its parent table, however it only it did not add certification keys for the parent table. This patch adds the following: * Append certification keys corresponding to all parent tables before DROP TABLE replication. * Fix wsrep_append_fk_parent_table() so that it works when it is given a table list containing temporary tables. * Make sure function wsrep_append_fk_parent_table() is only called for local transaction. That was not the case for ALTER TABLE. * Add a test case that verifies that UPDATE parent depends on preceeding DROP TABLE child. * Adapt galera_ddl_fk_conflict test to work with DROP TABLE as well. Signed-off-by: Julius Goryavsky <julius.goryavsky@mariadb.com>
83 lines
2.1 KiB
Text
83 lines
2.1 KiB
Text
#
|
|
# BF-BF conflict on MDL locks between: DROP TABLE t2 and UPDATE on t1
|
|
# with t2 referencing t1
|
|
#
|
|
|
|
--source include/galera_cluster.inc
|
|
--source include/have_debug_sync.inc
|
|
|
|
#
|
|
# Setup
|
|
#
|
|
--connection node_2
|
|
SET GLOBAL wsrep_slave_threads=2;
|
|
|
|
CREATE TABLE t1 (
|
|
id INTEGER PRIMARY KEY,
|
|
f2 INTEGER);
|
|
|
|
CREATE TABLE t2 (
|
|
f1 INT PRIMARY KEY,
|
|
t1_id INT NOT NULL,
|
|
f2 INTEGER NOT NULL,
|
|
KEY key_t1_id(t1_id),
|
|
CONSTRAINT key_t1_id FOREIGN KEY (t1_id) REFERENCES t1 (id) ON UPDATE CASCADE ON DELETE CASCADE);
|
|
|
|
INSERT INTO t1 VALUES (1,0);
|
|
INSERT INTO t1 VALUES (2,0);
|
|
|
|
INSERT INTO t2 VALUES (1,1,1234);
|
|
INSERT INTO t2 VALUES (2,2,1234);
|
|
|
|
#
|
|
# DROP TABLE t2 and wait for it to reach node_2
|
|
#
|
|
--connection node_2
|
|
SET GLOBAL DEBUG_DBUG = "d,sync.wsrep_apply_toi";
|
|
|
|
--connection node_1
|
|
DROP TABLE t2;
|
|
|
|
--connection node_2
|
|
SET DEBUG_SYNC = "now WAIT_FOR sync.wsrep_apply_toi_reached";
|
|
|
|
SET SESSION wsrep_sync_wait = 0;
|
|
--let $expected_apply_waits = `SELECT VARIABLE_VALUE+1 FROM information_schema.global_status WHERE VARIABLE_NAME = 'wsrep_apply_waits'`
|
|
--echo $expected_apply_waits
|
|
|
|
#
|
|
# Issue a UPDATE to table that references t1
|
|
# Notice that we update field f2, not the primary key,
|
|
# and not foreign key. Bug does not manifest if we update
|
|
# one of those fields (because FK keys appended in those cases).
|
|
#
|
|
--connection node_1
|
|
UPDATE t1 SET f2 = 1 WHERE id=2;
|
|
|
|
|
|
#
|
|
# Expect the UPDATE to depend on the DROP,
|
|
# therefore it should wait for the DROP to
|
|
# finish before it can be applied.
|
|
# If bug is present, expect the wait condition
|
|
# to timeout and when the UPDATE applies, it
|
|
# will be granted a MDL lock of type SHARED_READ
|
|
# for table t1. When resumed, the DROP TABLE will
|
|
# also try to MDL lock t1, causing a BF-BF conflict
|
|
# on that MDL lock.
|
|
#
|
|
--connection node_2
|
|
--let $wait_condition = SELECT VARIABLE_VALUE = $expected_apply_waits FROM information_schema.global_status WHERE VARIABLE_NAME = 'wsrep_apply_waits'
|
|
--source include/wait_condition.inc
|
|
SET DEBUG_SYNC = "now SIGNAL signal.wsrep_apply_toi";
|
|
|
|
SET SESSION wsrep_sync_wait = DEFAULT;
|
|
SELECT * FROM t1;
|
|
|
|
#
|
|
# Cleanup
|
|
#
|
|
SET DEBUG_SYNC = 'RESET';
|
|
SET GLOBAL DEBUG_DBUG = '';
|
|
SET GLOBAL wsrep_slave_threads = DEFAULT;
|
|
DROP TABLE t1;
|