mariadb/mysql-test/suite/innodb/t/foreign_key.test

502 lines
15 KiB
Text
Raw Normal View History

--source include/have_innodb.inc
MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246 MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2 by commit fec844aca88e1c6b9c36bb0b811e92d9d023ffb9 which introduced some Galera-specific conditions that were being evaluated even if the write-set replication was not enabled. MDEV-13246 Stale rows despite ON DELETE CASCADE constraint is a correctness regression that was introduced by the same commit. Especially the subcondition !(parent && que_node_get_type(parent) == QUE_NODE_UPDATE) which is equivalent to !parent || que_node_get_type(parent) != QUE_NODE_UPDATE makes little sense. If parent==NULL, the evaluation would proceed to the std::find() expression, which would dereference parent. Because no SIGSEGV was observed related to this, we can conclude that parent!=NULL always holds. But then, the condition would be equivalent to que_node_get_type(parent) != QUE_NODE_UPDATE which would not make sense either, because the std::find() expression is actually assuming the opposite when casting parent to upd_node_t*. It looks like this condition never worked properly, or that it was never properly tested, or both. wsrep_must_process_fk(): Helper function to check if FOREIGN KEY constraints need to be processed. Only evaluate the costly std::find() expression when write-set replication is enabled. Also, rely on operator<<(std::ostream&, const id_name_t&) and operator<<(std::ostream&, const table_name_t&) for pretty-printing index and table names. row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition. This is applying part of "Galera MW-369 FK fixes" https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52 that is described by the following part of the commit comment: additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has BF, essentially is applier or replaying This FK check would be needed only for populating parent row FK keys in write set, so no use for appliers
2017-08-14 16:01:08 +03:00
--source include/count_sessions.inc
--source include/default_charset.inc
--echo #
--echo # Bug #19027905 ASSERT RET.SECOND DICT_CREATE_FOREIGN_CONSTRAINTS_LOW
--echo # DICT_CREATE_FOREIGN_CONSTR
--echo #
create table t1 (f1 int primary key) engine=InnoDB;
--error ER_CANT_CREATE_TABLE
create table t2 (f1 int primary key,
constraint c1 foreign key (f1) references t1(f1),
constraint c1 foreign key (f1) references t1(f1)) engine=InnoDB;
create table t2 (f1 int primary key,
constraint c1 foreign key (f1) references t1(f1)) engine=innodb;
--error ER_CANT_CREATE_TABLE
alter table t2 add constraint c1 foreign key (f1) references t1(f1);
set foreign_key_checks = 0;
--error ER_DUP_CONSTRAINT_NAME
alter table t2 add constraint c1 foreign key (f1) references t1(f1);
drop table t2, t1;
--echo #
--echo # Bug #20031243 CREATE TABLE FAILS TO CHECK IF FOREIGN KEY COLUMN
--echo # NULL/NOT NULL MISMATCH
--echo #
set foreign_key_checks = 1;
show variables like 'foreign_key_checks';
CREATE TABLE t1
(a INT NOT NULL,
b INT NOT NULL,
INDEX idx(a)) ENGINE=InnoDB;
CREATE TABLE t2
(a INT KEY,
b INT,
INDEX ind(b),
FOREIGN KEY (b) REFERENCES t1(a) ON DELETE CASCADE ON UPDATE CASCADE)
ENGINE=InnoDB;
show create table t1;
show create table t2;
INSERT INTO t1 VALUES (1, 80);
INSERT INTO t1 VALUES (2, 81);
INSERT INTO t1 VALUES (3, 82);
INSERT INTO t1 VALUES (4, 83);
INSERT INTO t1 VALUES (5, 84);
INSERT INTO t2 VALUES (51, 1);
INSERT INTO t2 VALUES (52, 2);
INSERT INTO t2 VALUES (53, 3);
INSERT INTO t2 VALUES (54, 4);
INSERT INTO t2 VALUES (55, 5);
SELECT a, b FROM t1 ORDER BY a;
SELECT a, b FROM t2 ORDER BY a;
--error ER_NO_REFERENCED_ROW_2
INSERT INTO t2 VALUES (56, 6);
ALTER TABLE t1 CHANGE a id INT;
SELECT id, b FROM t1 ORDER BY id;
SELECT a, b FROM t2 ORDER BY a;
--echo # Operations on child table
--error ER_NO_REFERENCED_ROW_2
INSERT INTO t2 VALUES (56, 6);
--error ER_NO_REFERENCED_ROW_2
UPDATE t2 SET b = 99 WHERE a = 51;
DELETE FROM t2 WHERE a = 53;
SELECT id, b FROM t1 ORDER BY id;
SELECT a, b FROM t2 ORDER BY a;
--echo # Operations on parent table
DELETE FROM t1 WHERE id = 1;
UPDATE t1 SET id = 50 WHERE id = 5;
SELECT id, b FROM t1 ORDER BY id;
SELECT a, b FROM t2 ORDER BY a;
DROP TABLE t2, t1;
--echo #
--echo # bug#25126722 FOREIGN KEY CONSTRAINT NAME IS NULL AFTER RESTART
--echo # base bug#24818604 [GR]
--echo #
CREATE TABLE t1 (c1 INT PRIMARY KEY) ENGINE=InnoDB;
CREATE TABLE t2 (c1 INT PRIMARY KEY, FOREIGN KEY (c1) REFERENCES t1(c1))
ENGINE=InnoDB;
INSERT INTO t1 VALUES (1);
INSERT INTO t2 VALUES (1);
SELECT unique_constraint_name FROM information_schema.referential_constraints
WHERE table_name = 't2';
--source include/restart_mysqld.inc
SET @saved_frequency = @@GLOBAL.innodb_purge_rseg_truncate_frequency;
SET GLOBAL innodb_purge_rseg_truncate_frequency = 1;
SELECT unique_constraint_name FROM information_schema.referential_constraints
WHERE table_name = 't2';
SELECT * FROM t1;
SELECT unique_constraint_name FROM information_schema.referential_constraints
WHERE table_name = 't2';
DROP TABLE t2;
DROP TABLE t1;
#
# MDEV-12669 Circular foreign keys cause a loop and OOM upon LOCK TABLE
#
SET FOREIGN_KEY_CHECKS=0;
CREATE TABLE staff (
staff_id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
store_id TINYINT UNSIGNED NOT NULL,
PRIMARY KEY (staff_id),
KEY idx_fk_store_id (store_id),
CONSTRAINT fk_staff_store FOREIGN KEY (store_id) REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;
CREATE TABLE store (
store_id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
manager_staff_id TINYINT UNSIGNED NOT NULL,
PRIMARY KEY (store_id),
UNIQUE KEY idx_unique_manager (manager_staff_id),
CONSTRAINT fk_store_staff FOREIGN KEY (manager_staff_id) REFERENCES staff (staff_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;
SET FOREIGN_KEY_CHECKS=DEFAULT;
LOCK TABLE staff WRITE;
UNLOCK TABLES;
DROP TABLES staff, store;
MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246 MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2 by commit fec844aca88e1c6b9c36bb0b811e92d9d023ffb9 which introduced some Galera-specific conditions that were being evaluated even if the write-set replication was not enabled. MDEV-13246 Stale rows despite ON DELETE CASCADE constraint is a correctness regression that was introduced by the same commit. Especially the subcondition !(parent && que_node_get_type(parent) == QUE_NODE_UPDATE) which is equivalent to !parent || que_node_get_type(parent) != QUE_NODE_UPDATE makes little sense. If parent==NULL, the evaluation would proceed to the std::find() expression, which would dereference parent. Because no SIGSEGV was observed related to this, we can conclude that parent!=NULL always holds. But then, the condition would be equivalent to que_node_get_type(parent) != QUE_NODE_UPDATE which would not make sense either, because the std::find() expression is actually assuming the opposite when casting parent to upd_node_t*. It looks like this condition never worked properly, or that it was never properly tested, or both. wsrep_must_process_fk(): Helper function to check if FOREIGN KEY constraints need to be processed. Only evaluate the costly std::find() expression when write-set replication is enabled. Also, rely on operator<<(std::ostream&, const id_name_t&) and operator<<(std::ostream&, const table_name_t&) for pretty-printing index and table names. row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition. This is applying part of "Galera MW-369 FK fixes" https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52 that is described by the following part of the commit comment: additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has BF, essentially is applier or replaying This FK check would be needed only for populating parent row FK keys in write set, so no use for appliers
2017-08-14 16:01:08 +03:00
SET FOREIGN_KEY_CHECKS=1;
--echo #
--echo # MDEV-17531 Crash in RENAME TABLE with FOREIGN KEY and FULLTEXT INDEX
--echo #
--disable_query_log
2018-11-06 08:41:48 +02:00
call mtr.add_suppression("InnoDB: Possible reasons:");
call mtr.add_suppression("InnoDB: \\([12]\\) Table ");
call mtr.add_suppression("InnoDB: If table `test`\\.`t2` is a temporary table");
call mtr.add_suppression("InnoDB: Cannot delete/update rows with cascading foreign key constraints that exceed max depth of 15\\.");
--enable_query_log
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
CREATE DATABASE best default character set latin1;
CREATE TABLE t3 (a INT PRIMARY KEY,
CONSTRAINT t2_ibfk_1 FOREIGN KEY (a) REFERENCES t1(a)) ENGINE=InnoDB;
CREATE TABLE best.t2 (a INT PRIMARY KEY, b TEXT, FULLTEXT INDEX(b),
FOREIGN KEY (a) REFERENCES test.t1(a)) ENGINE=InnoDB;
--replace_regex /Table '.*t2'/Table 't2'/
--error ER_TABLE_EXISTS_ERROR
RENAME TABLE best.t2 TO test.t2;
SHOW CREATE TABLE best.t2;
DROP DATABASE best;
--echo #
--echo # MDEV-17541 KILL QUERY during lock wait in FOREIGN KEY check hangs
--echo #
connect (con1, localhost, root,,);
INSERT INTO t1 SET a=1;
BEGIN;
DELETE FROM t1;
connection default;
let $ID= `SELECT @id := CONNECTION_ID()`;
send INSERT INTO t3 SET a=1;
connection con1;
# Check that the above SELECT is blocked
let $wait_condition=
select count(*) = 1 from information_schema.processlist
where state = 'update' and info = 'INSERT INTO t3 SET a=1';
--source include/wait_condition.inc
let $ignore= `SELECT @id := $ID`;
kill query @id;
connection default;
--error ER_QUERY_INTERRUPTED
reap;
connection con1;
ROLLBACK;
connection default;
DROP TABLE t3,t1;
2018-11-06 08:41:48 +02:00
--echo #
--echo # MDEV-18222 InnoDB: Failing assertion: heap->magic_n == MEM_BLOCK_MAGIC_N
--echo # or ASAN heap-use-after-free in dict_foreign_remove_from_cache upon CHANGE COLUMN
--echo #
CREATE TABLE t1 (a INT, UNIQUE(a), KEY(a)) ENGINE=InnoDB;
ALTER TABLE t1 ADD FOREIGN KEY (a) REFERENCES t1 (a);
SET SESSION FOREIGN_KEY_CHECKS = OFF;
ALTER TABLE t1 CHANGE COLUMN a a TIME NOT NULL;
ALTER TABLE t1 ADD pk INT NOT NULL AUTO_INCREMENT PRIMARY KEY;
ALTER TABLE t1 CHANGE COLUMN a b TIME;
SET SESSION FOREIGN_KEY_CHECKS = ON;
DROP TABLE t1;
--echo #
--echo # MDEV-18256 InnoDB: Failing assertion: heap->magic_n == MEM_BLOCK_MAGIC_N
--echo # upon DROP FOREIGN KEY
--echo #
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
CREATE TABLE t2 (b INT PRIMARY KEY, FOREIGN KEY fk1 (b) REFERENCES t1 (a))
ENGINE=InnoDB;
ALTER TABLE t2 DROP FOREIGN KEY fk1, DROP FOREIGN KEY fk1;
DROP TABLE t2, t1;
CREATE TABLE t1 (f VARCHAR(256)) ENGINE=InnoDB;
SET SESSION FOREIGN_KEY_CHECKS = OFF;
ALTER TABLE t1 ADD FOREIGN KEY (f) REFERENCES non_existing_table (x);
SET SESSION FOREIGN_KEY_CHECKS = ON;
ALTER TABLE t1 ADD FULLTEXT INDEX ft1 (f);
ALTER TABLE t1 ADD FULLTEXT INDEX ft2 (f);
DROP TABLE t1;
CREATE TABLE t1 (f VARCHAR(256), FTS_DOC_ID BIGINT UNSIGNED PRIMARY KEY)
ENGINE=InnoDB;
SET SESSION FOREIGN_KEY_CHECKS = OFF;
ALTER TABLE t1 ADD FOREIGN KEY (f) REFERENCES non_existing_table (x);
SET SESSION FOREIGN_KEY_CHECKS = ON;
ALTER TABLE t1 ADD FULLTEXT INDEX ft1 (f);
ALTER TABLE t1 ADD FULLTEXT INDEX ft2 (f);
DROP TABLE t1;
2019-02-11 11:42:18 +02:00
--echo #
--echo # MDEV-18630 Conditional jump or move depends on uninitialised value
--echo # in ib_push_warning / dict_create_foreign_constraints_low
--echo #
CREATE TABLE t1 (a INT) ENGINE=InnoDB;
--error ER_CANT_CREATE_TABLE
ALTER IGNORE TABLE t1 ADD FOREIGN KEY (a) REFERENCES t2 (b);
SHOW WARNINGS;
DROP TABLE t1;
2019-02-18 22:21:02 +02:00
--echo #
--echo # MDEV-18139 ALTER IGNORE ... ADD FOREIGN KEY causes bogus error
--echo #
CREATE TABLE t1 (f1 INT, f2 INT, f3 INT, KEY(f1)) ENGINE=InnoDB;
CREATE TABLE t2 (f INT, KEY(f)) ENGINE=InnoDB;
ALTER TABLE t1 ADD FOREIGN KEY (f2) REFERENCES t2 (f);
ALTER IGNORE TABLE t1 ADD FOREIGN KEY (f3) REFERENCES t1 (f1);
DROP TABLE t1, t2;
2019-04-25 09:04:09 +03:00
2018-11-06 08:41:48 +02:00
--echo # Start of 10.2 tests
MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246 MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2 by commit fec844aca88e1c6b9c36bb0b811e92d9d023ffb9 which introduced some Galera-specific conditions that were being evaluated even if the write-set replication was not enabled. MDEV-13246 Stale rows despite ON DELETE CASCADE constraint is a correctness regression that was introduced by the same commit. Especially the subcondition !(parent && que_node_get_type(parent) == QUE_NODE_UPDATE) which is equivalent to !parent || que_node_get_type(parent) != QUE_NODE_UPDATE makes little sense. If parent==NULL, the evaluation would proceed to the std::find() expression, which would dereference parent. Because no SIGSEGV was observed related to this, we can conclude that parent!=NULL always holds. But then, the condition would be equivalent to que_node_get_type(parent) != QUE_NODE_UPDATE which would not make sense either, because the std::find() expression is actually assuming the opposite when casting parent to upd_node_t*. It looks like this condition never worked properly, or that it was never properly tested, or both. wsrep_must_process_fk(): Helper function to check if FOREIGN KEY constraints need to be processed. Only evaluate the costly std::find() expression when write-set replication is enabled. Also, rely on operator<<(std::ostream&, const id_name_t&) and operator<<(std::ostream&, const table_name_t&) for pretty-printing index and table names. row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition. This is applying part of "Galera MW-369 FK fixes" https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52 that is described by the following part of the commit comment: additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has BF, essentially is applier or replaying This FK check would be needed only for populating parent row FK keys in write set, so no use for appliers
2017-08-14 16:01:08 +03:00
--echo #
--echo # MDEV-13246 Stale rows despite ON DELETE CASCADE constraint
--echo #
CREATE TABLE users (
id int unsigned AUTO_INCREMENT PRIMARY KEY,
name varchar(32) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE matchmaking_groups (
id bigint unsigned AUTO_INCREMENT PRIMARY KEY,
host_user_id int unsigned NOT NULL UNIQUE,
CONSTRAINT FOREIGN KEY (host_user_id) REFERENCES users (id)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE matchmaking_group_users (
matchmaking_group_id bigint unsigned NOT NULL,
user_id int unsigned NOT NULL,
PRIMARY KEY (matchmaking_group_id,user_id),
UNIQUE KEY user_id (user_id),
CONSTRAINT FOREIGN KEY (matchmaking_group_id)
REFERENCES matchmaking_groups (id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT FOREIGN KEY (user_id)
REFERENCES users (id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
CREATE TABLE matchmaking_group_maps (
matchmaking_group_id bigint unsigned NOT NULL,
map_id tinyint unsigned NOT NULL,
PRIMARY KEY (matchmaking_group_id,map_id),
CONSTRAINT FOREIGN KEY (matchmaking_group_id)
REFERENCES matchmaking_groups (id) ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO users VALUES (NULL,'foo'),(NULL,'bar');
INSERT INTO matchmaking_groups VALUES (10,1),(11,2);
INSERT INTO matchmaking_group_users VALUES (10,1),(11,2);
INSERT INTO matchmaking_group_maps VALUES (10,55),(11,66);
BEGIN;
UPDATE users SET name = 'qux' WHERE id = 1;
--connection con1
MDEV-13498 DELETE with CASCADE constraints takes long time / MDEV-13246 MDEV-13498 is a performance regression that was introduced in MariaDB 10.2.2 by commit fec844aca88e1c6b9c36bb0b811e92d9d023ffb9 which introduced some Galera-specific conditions that were being evaluated even if the write-set replication was not enabled. MDEV-13246 Stale rows despite ON DELETE CASCADE constraint is a correctness regression that was introduced by the same commit. Especially the subcondition !(parent && que_node_get_type(parent) == QUE_NODE_UPDATE) which is equivalent to !parent || que_node_get_type(parent) != QUE_NODE_UPDATE makes little sense. If parent==NULL, the evaluation would proceed to the std::find() expression, which would dereference parent. Because no SIGSEGV was observed related to this, we can conclude that parent!=NULL always holds. But then, the condition would be equivalent to que_node_get_type(parent) != QUE_NODE_UPDATE which would not make sense either, because the std::find() expression is actually assuming the opposite when casting parent to upd_node_t*. It looks like this condition never worked properly, or that it was never properly tested, or both. wsrep_must_process_fk(): Helper function to check if FOREIGN KEY constraints need to be processed. Only evaluate the costly std::find() expression when write-set replication is enabled. Also, rely on operator<<(std::ostream&, const id_name_t&) and operator<<(std::ostream&, const table_name_t&) for pretty-printing index and table names. row_upd_sec_index_entry(): Add !wsrep_thd_is_BF() to the condition. This is applying part of "Galera MW-369 FK fixes" https://github.com/codership/mysql-wsrep/commit/f37b79c6dab101310a45a9e8cb23c0f98716da52 that is described by the following part of the commit comment: additionally: skipping wsrep_row_upd_check_foreign_constraint if thd has BF, essentially is applier or replaying This FK check would be needed only for populating parent row FK keys in write set, so no use for appliers
2017-08-14 16:01:08 +03:00
SET innodb_lock_wait_timeout= 1;
DELETE FROM matchmaking_groups WHERE id = 10;
--connection default
COMMIT;
--sorted_result
SELECT * FROM matchmaking_group_users WHERE matchmaking_group_id NOT IN (SELECT id FROM matchmaking_groups);
--sorted_result
SELECT * FROM matchmaking_group_maps WHERE matchmaking_group_id NOT IN (SELECT id FROM matchmaking_groups);
--sorted_result
SELECT * FROM users;
DROP TABLE
matchmaking_group_maps, matchmaking_group_users, matchmaking_groups, users;
--echo #
--echo # MDEV-13331 FK DELETE CASCADE does not honor innodb_lock_wait_timeout
--echo #
CREATE TABLE t1 (id INT NOT NULL PRIMARY KEY) ENGINE=InnoDB;
CREATE TABLE t2 (
id INT NOT NULL PRIMARY KEY,
ref_id INT NOT NULL DEFAULT 0,
f INT NULL,
FOREIGN KEY (ref_id) REFERENCES t1 (id) ON DELETE CASCADE
) ENGINE=InnoDB;
INSERT INTO t1 VALUES (1),(2);
INSERT INTO t2 VALUES (1,1,10),(2,2,20);
SHOW CREATE TABLE t2;
--connection con1
BEGIN;
UPDATE t2 SET f = 11 WHERE id = 1;
--connection default
SET innodb_lock_wait_timeout= 1;
--error ER_LOCK_WAIT_TIMEOUT
DELETE FROM t1 WHERE id = 1;
--connection con1
COMMIT;
--connection default
SELECT * FROM t2;
DELETE FROM t1 WHERE id = 1;
SELECT * FROM t2;
DROP TABLE t2, t1;
--echo #
--echo # MDEV-15199 Referential integrity broken in ON DELETE CASCADE
--echo #
CREATE TABLE member (id int AUTO_INCREMENT PRIMARY KEY) ENGINE=InnoDB;
INSERT INTO member VALUES (1);
CREATE TABLE address (
id int AUTO_INCREMENT PRIMARY KEY,
member_id int NOT NULL,
KEY address_FI_1 (member_id),
CONSTRAINT address_FK_1 FOREIGN KEY (member_id) REFERENCES member (id)
ON DELETE CASCADE ON UPDATE CASCADE
) ENGINE=InnoDB;
INSERT INTO address VALUES (2,1);
CREATE TABLE payment_method (
id int AUTO_INCREMENT PRIMARY KEY,
member_id int NOT NULL,
cardholder_address_id int DEFAULT NULL,
KEY payment_method_FI_1 (member_id),
KEY payment_method_FI_2 (cardholder_address_id),
CONSTRAINT payment_method_FK_1 FOREIGN KEY (member_id) REFERENCES member (id) ON DELETE CASCADE ON UPDATE CASCADE,
CONSTRAINT payment_method_FK_2 FOREIGN KEY (cardholder_address_id) REFERENCES address (id) ON DELETE SET NULL ON UPDATE CASCADE
) ENGINE=InnoDB;
INSERT INTO payment_method VALUES (3,1,2);
BEGIN;
UPDATE member SET id=42;
SELECT * FROM member;
SELECT * FROM address;
SELECT * FROM payment_method;
DELETE FROM member;
COMMIT;
SELECT * FROM member;
SELECT * FROM address;
SELECT * FROM payment_method;
DROP TABLE payment_method,address,member;
--echo #
--echo # Bug #26958695 INNODB NESTED STORED FIELD WITH CONSTRAINT KEY
--echo # PRODUCE BROKEN TABLE (no bug in MariaDB)
--echo #
create table t1(f1 int,f2 int, primary key(f1), key(f2, f1))engine=innodb;
create table t2(f1 int, f2 int as (2) stored, f3 int as (f2) stored,
foreign key(f1) references t1(f2) on update set NULL)
engine=innodb;
insert into t1 values(1, 1);
insert into t2(f1) values(1);
drop table t2, t1;
#
# MDEV-12669 Circular foreign keys cause a loop and OOM upon LOCK TABLE
#
SET FOREIGN_KEY_CHECKS=0;
CREATE TABLE staff (
staff_id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
store_id TINYINT UNSIGNED NOT NULL,
PRIMARY KEY (staff_id),
KEY idx_fk_store_id (store_id),
CONSTRAINT fk_staff_store FOREIGN KEY (store_id) REFERENCES store (store_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;
CREATE TABLE store (
store_id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT,
manager_staff_id TINYINT UNSIGNED NOT NULL,
PRIMARY KEY (store_id),
UNIQUE KEY idx_unique_manager (manager_staff_id),
CONSTRAINT fk_store_staff FOREIGN KEY (manager_staff_id) REFERENCES staff (staff_id) ON DELETE RESTRICT ON UPDATE CASCADE
) ENGINE=InnoDB;
LOCK TABLE staff WRITE;
UNLOCK TABLES;
DROP TABLES staff, store;
SET FOREIGN_KEY_CHECKS=1;
--echo #
--echo # MDEV-17541 KILL QUERY during lock wait in FOREIGN KEY check hangs
--echo #
CREATE TABLE t1 (a INT PRIMARY KEY) ENGINE=InnoDB;
CREATE TABLE t2 (a INT PRIMARY KEY, FOREIGN KEY (a) REFERENCES t1(a))
ENGINE=InnoDB;
connection con1;
INSERT INTO t1 SET a=1;
BEGIN;
DELETE FROM t1;
connection default;
let $ID= `SELECT @id := CONNECTION_ID()`;
send INSERT INTO t2 SET a=1;
connection con1;
let $wait_condition=
select count(*) = 1 from information_schema.processlist
where state = 'update' and info = 'INSERT INTO t2 SET a=1';
--source include/wait_condition.inc
let $ignore= `SELECT @id := $ID`;
kill query @id;
connection default;
--error ER_QUERY_INTERRUPTED
reap;
connection con1;
ROLLBACK;
connection default;
DROP TABLE t2,t1;
--echo #
--echo # MDEV-18272 InnoDB index corruption after failed DELETE CASCADE
--echo #
CREATE TABLE t1 (
pk TINYINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
a TINYINT UNSIGNED NOT NULL, b TINYINT UNSIGNED NOT NULL, KEY(b),
CONSTRAINT FOREIGN KEY (a) REFERENCES t1 (b) ON DELETE CASCADE
) ENGINE=InnoDB;
INSERT INTO t1 (a,b) VALUES
(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),(0,0),
(0,1),(0,1),(1,0);
connection con1;
START TRANSACTION WITH CONSISTENT SNAPSHOT;
connection default;
DELETE IGNORE FROM t1 WHERE b = 1;
SELECT a FROM t1 FORCE INDEX(a);
# This would wrongly return the empty result if
# the "goto rollback_to_savept" in row_mysql_handle_errors() is reverted.
SELECT * FROM t1;
# Allow purge to continue by closing the read view.
disconnect con1;
# Wait for purge. With the fix reverted, the server would crash here.
--source include/wait_all_purged.inc
CHECK TABLE t1;
DROP TABLE t1;
SET GLOBAL innodb_purge_rseg_truncate_frequency = @saved_frequency;
2018-11-06 08:41:48 +02:00
--echo # End of 10.2 tests
--source include/wait_until_count_sessions.inc