File: MDEV-35018.test

package info (click to toggle)
mariadb 1%3A11.8.2-1
  • links: PTS, VCS
  • area: main
  • in suites: forky, trixie
  • size: 765,428 kB
  • sloc: ansic: 2,382,827; cpp: 1,803,532; asm: 378,315; perl: 63,176; sh: 46,496; pascal: 40,776; java: 39,363; yacc: 20,428; python: 19,506; sql: 17,864; xml: 12,463; ruby: 8,544; makefile: 6,059; cs: 5,855; ada: 1,700; lex: 1,193; javascript: 1,039; objc: 80; tcl: 73; awk: 46; php: 22
file content (83 lines) | stat: -rw-r--r-- 2,194 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
#
# 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;