Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.2(EOL), 10.3(EOL), 10.4(EOL), 10.5, 10.6
-
None
Description
--source include/have_innodb.inc
|
--source include/have_sequence.inc
|
|
CREATE TABLE t1 ( |
id INT AUTO_INCREMENT PRIMARY KEY, |
c CHAR(120) DEFAULT '', |
k INT DEFAULT 0, |
p CHAR(60) DEFAULT '' |
) ENGINE=InnoDB;
|
INSERT INTO t1 (id) SELECT seq FROM seq_1_to_2400; |
|
CREATE TABLE t2 ( |
id INT PRIMARY KEY, |
FOREIGN KEY (id) REFERENCES t1 (id) |
) ENGINE=InnoDB;
|
|
SET FOREIGN_KEY_CHECKS = OFF; |
ALTER TABLE t2 MODIFY id DOUBLE; |
SET FOREIGN_KEY_CHECKS = ON; |
ALTER TABLE t2 FORCE; |
INSERT INTO t2 (id) VALUES (1); |
|
SELECT * FROM t2; |
|
# Cleanup
|
DROP TABLE t2, t1; |
10.5 5adcb2e7 |
2021-01-25 16:49:12 4 [Warning] InnoDB: In ALTER TABLE `test`.`t2` has or is referenced in foreign key constraints which are not compatible with the new table definition.
|
2021-01-25 16:49:12 0x7f62180ce700 InnoDB: Assertion failure in file /data/src/10.5/storage/innobase/row/row0ins.cc line 1781
|
InnoDB: Failing assertion: cmp < 0
|
|
#5 0x00007f621c973859 in __GI_abort () at abort.c:79
|
#6 0x0000556482843024 in ut_dbg_assertion_failed (expr=0x556482f08f99 "cmp < 0", file=0x556482f08180 "/data/src/10.5/storage/innobase/row/row0ins.cc", line=1781) at /data/src/10.5/storage/innobase/ut/ut0dbg.cc:60
|
#7 0x000055648273c135 in row_ins_check_foreign_constraint (check_ref=1, foreign=0x7f61e41e9628, table=0x7f61e405b938, entry=0x7f61e406a038, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:1781
|
#8 0x000055648273c8b9 in row_ins_check_foreign_constraints (table=0x7f61e405b938, index=0x7f61e405c488, pk=true, entry=0x55648444be88, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:1982
|
#9 0x0000556482740718 in row_ins_clust_index_entry (index=0x7f61e405c488, entry=0x55648444be88, thr=0x7f61e406ae60, n_ext=0) at /data/src/10.5/storage/innobase/row/row0ins.cc:3161
|
#10 0x0000556482740dc4 in row_ins_index_entry (index=0x7f61e405c488, entry=0x55648444be88, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3333
|
#11 0x000055648274169a in row_ins_index_entry_step (node=0x7f61e406ac30, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3502
|
#12 0x0000556482741bba in row_ins (node=0x7f61e406ac30, thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3661
|
#13 0x00005564827424da in row_ins_step (thr=0x7f61e406ae60) at /data/src/10.5/storage/innobase/row/row0ins.cc:3807
|
#14 0x0000556482766c68 in row_insert_for_mysql (mysql_rec=0x7f61e405a538 "\377", prebuilt=0x7f61e406a738, ins_mode=ROW_INS_NORMAL) at /data/src/10.5/storage/innobase/row/row0mysql.cc:1421
|
#15 0x00005564825af32d in ha_innobase::write_row (this=0x7f61e4063e60, record=0x7f61e405a538 "\377") at /data/src/10.5/storage/innobase/handler/ha_innodb.cc:7544
|
#16 0x0000556482142c87 in handler::ha_write_row (this=0x7f61e4063e60, buf=0x7f61e405a538 "\377") at /data/src/10.5/sql/handler.cc:7151
|
#17 0x0000556481d760f9 in write_record (thd=0x7f61e4000db8, table=0x7f61e4067038, info=0x7f62180ccbe0, sink=0x0) at /data/src/10.5/sql/sql_insert.cc:2106
|
#18 0x0000556481d72e33 in mysql_insert (thd=0x7f61e4000db8, table_list=0x7f61e4014010, fields=..., values_list=..., update_fields=..., update_values=..., duplic=DUP_ERROR, ignore=false, result=0x0) at /data/src/10.5/sql/sql_insert.cc:1099
|
#19 0x0000556481dc6596 in mysql_execute_command (thd=0x7f61e4000db8) at /data/src/10.5/sql/sql_parse.cc:4596
|
#20 0x0000556481dd22b0 in mysql_parse (thd=0x7f61e4000db8, rawbuf=0x7f61e4013f30 "INSERT INTO t2 (id) VALUES (1)", length=30, parser_state=0x7f62180cd510, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:8062
|
#21 0x0000556481dbe237 in dispatch_command (command=COM_QUERY, thd=0x7f61e4000db8, packet=0x7f61e40090a9 "INSERT INTO t2 (id) VALUES (1)", packet_length=30, is_com_multi=false, is_next_command=false) at /data/src/10.5/sql/sql_parse.cc:1889
|
#22 0x0000556481dbca2b in do_command (thd=0x7f61e4000db8) at /data/src/10.5/sql/sql_parse.cc:1370
|
#23 0x0000556481f6a72b in do_handle_one_connection (connect=0x5564848a9c78, put_in_cache=true) at /data/src/10.5/sql/sql_connect.cc:1410
|
#24 0x0000556481f6a48e in handle_one_connection (arg=0x556484834238) at /data/src/10.5/sql/sql_connect.cc:1312
|
#25 0x00005564824c9449 in pfs_spawn_thread (arg=0x5564847c8358) at /data/src/10.5/storage/perfschema/pfs.cc:2201
|
#26 0x00007f621ce9c609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#27 0x00007f621ca70293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
The assertion failure is reproducible on 10.5/10.6, debug and release builds alike.
Previous versions don't crash, but the behavior is still odd:
10.2 1a999585 |
SET FOREIGN_KEY_CHECKS = OFF; |
ALTER TABLE t2 MODIFY id DOUBLE; |
SET FOREIGN_KEY_CHECKS = ON; |
ALTER TABLE t2 FORCE; |
Warnings:
|
Warning 1088 failed to load FOREIGN KEY constraints |
SHOW CREATE TABLE t2; |
Table Create Table |
t2 CREATE TABLE `t2` ( |
`id` double NOT NULL, |
PRIMARY KEY (`id`) |
) ENGINE=InnoDB DEFAULT CHARSET=latin1 |
INSERT INTO t2 (id) VALUES (1); |
SELECT * FROM t2; |
id
|
1
|
DROP TABLE t2, t1; |
So, even though FOREIGN_KEY_CHECKS is back ON, ALTER TABLE t2 FORCE is allowed to happen. The foreign key gets disabled (it isn't even shown in SHOW CREATE TABLE anymore), and further INSERT works without complaints.
Both the current behavior and the assertion failure in higher versions started happening after this commit:
commit 8268f26605c871f19cb78be08c84f621f4e0c4cb
|
Author: Thirunarayanan Balathandayuthapani
|
Date: Fri Aug 7 19:02:48 2020 +0530
|
|
MDEV-22934 Table disappear after two alter table command
|
Before this patch, ALTER TABLE t2 MODIFY id DOUBLE was failing with ER_ERROR_ON_RENAME despite FOREIGN_KEY_CHECKS being OFF at that time.
I'm not sure what is the expected behavior, disabling FOREIGN_KEY_CHECKS tends to cause controversial results. Except that it shouldn't crash or corrupt data, of course.
Attachments
Issue Links
- is duplicated by
-
MDEV-31086 MODIFY COLUMN can break FK constraints, and lead to unrestorable dumps
- Closed