File: galera_ddl_fk_no_conflict.inc

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 (34 lines) | stat: -rw-r--r-- 1,103 bytes parent folder | download | duplicates (5)
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
# This test attempts to show that OPTIMIZE on a child table does NOT
# acquire MDL locks on the parent table. #
# param: $table_admin_command
#        DDL table command to test, script will build full SQL statement:
#        $table_admin_command TABLE c;
#
# param: $FK_constraint
#        Foreign key constraint to use when creating the child table.
#

CREATE TABLE parent (pk INTEGER PRIMARY KEY);
--eval CREATE TABLE child (pk INTEGER PRIMARY KEY, parent_id INTEGER, FOREIGN KEY(parent_id) REFERENCES parent(pk) $fk_constraint)

INSERT INTO parent VALUES (1), (2), (3), (4);
INSERT INTO child VALUES (1,1), (2,2), (3,3), (4,4);

--connection node_1
# Start a transaction that uses the parent table,
# so that we acquire MDL lock on parent.
START TRANSACTION;
SELECT * FROM parent FOR UPDATE;

# In a different connection, execute the table
# admin command (OPTIMIZE / REPAIR ...) on the child table.
--connect node_1a, 127.0.0.1, root, , test, $NODE_MYPORT_1
--eval $table_admin_command TABLE child;

# Expect no conflict.
--connection node_1
COMMIT;

DROP TABLE child, parent;

--disconnect node_1a