Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
N/A
Description
--source include/have_innodb.inc
|
|
|
SET FOREIGN_KEY_CHECKS= OFF; |
CREATE TABLE t1 (pk INT PRIMARY KEY, f INT, FOREIGN KEY (f) REFERENCES t4 (x)) ENGINE=InnoDB; |
ALTER TABLE t1 DROP KEY f; |
CREATE TABLE t2 (a INT) ENGINE=InnoDB; |
--error ER_ERROR_ON_RENAME
|
RENAME TABLE t1 TO t3, t3 TO t4; |
RENAME TABLE t2 TO t3; |
In the test case above, the second part of the first RENAME query fails with "Foreign key constraint is incorrectly formed", apparently because by dropping the key we've made things so bad that even FOREIGN_KEYS=OFF doesn't help anymore. (Whether it should fail or not is another question, but it was so before atomic DDL and is unrelated to it).
Before atomic DDL it would leave us with t1 renamed to t3, so the next RENAME query would fail with "table already exists".
With the atomic DDL t1 seemingly remains to be t1. But then the 2nd RENAME query fails on the assertion:
|
bb-10.6-monty with the trigger patch |
2021-04-25 0:04:20 4 [ERROR] InnoDB: In RENAME TABLE table `test`.`t4` is referenced in foreign key constraints which are not compatible with the new table definition.
|
2021-04-25 0:04:20 4 [ERROR] InnoDB: In RENAME TABLE table `test`.`t1` is referenced in foreign key constraints which are not compatible with the new table definition.
|
mariadbd: /data/src/bb-10.6-monty-patch/storage/innobase/row/row0mysql.cc:4248: dberr_t row_rename_table_for_mysql(const char*, const char*, trx_t*, bool, bool): Assertion `err != DB_DUPLICATE_KEY' failed.
|
210425 0:04:20 [ERROR] mysqld got signal 6 ;
|
|
|
x55b6ffb2a180 "dberr_t row_rename_table_for_mysql(const char*, const char*, trx_t*, bool, bool)") at assert.c:101
|
#8 0x000055b6fe5bd167 in row_rename_table_for_mysql (old_name=0x7f3585cc4940 "test/t2", new_name=0x7f3585cc4700 "test/t3", trx=0x7f358bc88a90, commit=true, use_fk=true) at /data/src/bb-10.6-monty-patch/storage/innobase/row/row0mysql.cc:4248
|
#9 0x000055b6fe262877 in innobase_rename_table (trx=0x7f358bc88a90, from=0x7f3585cc5b20 "./test/t2", to=0x7f3585cc5d60 "./test/t3", commit=true) at /data/src/bb-10.6-monty-patch/storage/innobase/handler/ha_innodb.cc:13341
|
#10 0x000055b6fe22b50e in ha_innobase::rename_table (this=0x62b0000a9580, from=0x7f3585cc5b20 "./test/t2", to=0x7f3585cc5d60 "./test/t3") at /data/src/bb-10.6-monty-patch/storage/innobase/handler/ha_innodb.cc:13534
|
#11 0x000055b6fd6ffda7 in handler::ha_rename_table (this=0x62b0000a9580, from=0x7f3585cc5b20 "./test/t2", to=0x7f3585cc5d60 "./test/t3") at /data/src/bb-10.6-monty-patch/sql/handler.cc:5025
|
#12 0x000055b6fd13235c in mysql_rename_table (base=0x616000021d08, old_db=0x62b0000a8400, old_name=0x7f3585cc6b60, new_db=0x62b0000a8b00, new_name=0x7f3585cc6b70, id=0x7f3585cc6b80, flags=0) at /data/src/bb-10.6-monty-patch/sql/sql_table.cc:4941
|
#13 0x000055b6fcf25a8e in do_rename (thd=0x62b0000d9288, param=0x7f3585cc6b60, ddl_log_state=0x7f3585cc6ca0, ren_table=0x62b0000a83e8, new_db=0x62b0000a8b00, skip_error=false, force_if_exists=0x7f3585cc6c90) at /data/src/bb-10.6-monty-patch/sql/sql_rename.cc:383
|
#14 0x000055b6fcf2640a in rename_tables (thd=0x62b0000d9288, table_list=0x62b0000a83e8, ddl_log_state=0x7f3585cc6ca0, skip_error=false, if_exists=false, force_if_exists=0x7f3585cc6c90) at /data/src/bb-10.6-monty-patch/sql/sql_rename.cc:533
|
#15 0x000055b6fcf2436f in mysql_rename_tables (thd=0x62b0000d9288, table_list=0x62b0000a83e8, silent=false, if_exists=false) at /data/src/bb-10.6-monty-patch/sql/sql_rename.cc:164
|
#16 0x000055b6fceaaf70 in mysql_execute_command (thd=0x62b0000d9288) at /data/src/bb-10.6-monty-patch/sql/sql_parse.cc:4323
|
#17 0x000055b6fcec57f5 in mysql_parse (thd=0x62b0000d9288, rawbuf=0x62b0000a82a8 "RENAME TABLE t2 TO t3", length=21, parser_state=0x7f3585cc79a0) at /data/src/bb-10.6-monty-patch/sql/sql_parse.cc:8019
|
#18 0x000055b6fce9b7fd in dispatch_command (command=COM_QUERY, thd=0x62b0000d9288, packet=0x629000294289 "RENAME TABLE t2 TO t3", packet_length=21, blocking=true) at /data/src/bb-10.6-monty-patch/sql/sql_parse.cc:1897
|
#19 0x000055b6fce9851e in do_command (thd=0x62b0000d9288, blocking=true) at /data/src/bb-10.6-monty-patch/sql/sql_parse.cc:1406
|
#20 0x000055b6fd2f7d88 in do_handle_one_connection (connect=0x611000021908, put_in_cache=true) at /data/src/bb-10.6-monty-patch/sql/sql_connect.cc:1410
|
#21 0x000055b6fd2f76e5 in handle_one_connection (arg=0x6110000217c8) at /data/src/bb-10.6-monty-patch/sql/sql_connect.cc:1312
|
#22 0x000055b6fe007ad1 in pfs_spawn_thread (arg=0x618000007908) at /data/src/bb-10.6-monty-patch/storage/perfschema/pfs.cc:2201
|
#23 0x00007f359549e609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#24 0x00007f3595072293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Note: I've left the test case without a cleanup, because I don't really know what should happen after the 2nd RENAME, other than that it shouldn't crash. It depends on why exactly the previous foreign key check failed despite foreign key checks being disabled.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
-
- Closed
-