Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Cannot Reproduce
-
10.3, 10.4, 10.5
Description
CREATE SEQUENCE s; |
LOCK TABLE s WRITE; |
ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000); |
|
# Cleanup
|
DROP SEQUENCE s; |
ALTER above causes ER_KEY_NOT_FOUND on release and debug builds:
10.3 38d62189 |
mysqltest: At line 5: query 'ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000)' failed: 1032: Can't find record in 's'
|
It is also written into the error log.
It is quite bad, because ER_KEY_NOT_FOUND normally indicates data corruption and thus would alarm users.
Reproducible on 10.3-10.5.
If we add binary logging to the scenario, we also get a debug assertion failure:
--source include/have_log_bin.inc
|
|
CREATE SEQUENCE s; |
LOCK TABLE s WRITE; |
ALTER IGNORE TABLE s ADD CHECK (maximum_value < 1000000); |
|
# Cleanup
|
DROP SEQUENCE s; |
mysqld: /data/src/10.3/sql/protocol.cc:599: void Protocol::end_statement(): Assertion `0' failed.
|
200517 2:28:49 [ERROR] mysqld got signal 6 ;
|
|
#6 0x00007f028040de67 in __assert_fail_base (fmt=<optimized out>, assertion=assertion@entry=0x565278f72858 "0", file=file@entry=0x565278f72538 "/data/src/10.3/sql/protocol.cc", line=line@entry=599, function=function@entry=0x565278f731d0 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:92
|
#7 0x00007f028040df12 in __GI___assert_fail (assertion=0x565278f72858 "0", file=0x565278f72538 "/data/src/10.3/sql/protocol.cc", line=599, function=0x565278f731d0 <Protocol::end_statement()::__PRETTY_FUNCTION__> "void Protocol::end_statement()") at assert.c:101
|
#8 0x000056527822417a in Protocol::end_statement (this=0x7f025c0010a8) at /data/src/10.3/sql/protocol.cc:599
|
#9 0x0000565278337189 in dispatch_command (command=COM_QUERY, thd=0x7f025c000af0, packet=0x7f025c1233b1 "", packet_length=56, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:2412
|
#10 0x0000565278333d67 in do_command (thd=0x7f025c000af0) at /data/src/10.3/sql/sql_parse.cc:1401
|
#11 0x00005652784ac017 in do_handle_one_connection (connect=0x56527c53c880) at /data/src/10.3/sql/sql_connect.cc:1403
|
#12 0x00005652784abd79 in handle_one_connection (arg=0x56527c53c880) at /data/src/10.3/sql/sql_connect.cc:1308
|
#13 0x0000565278e6070c in pfs_spawn_thread (arg=0x56527c4a1150) at /data/src/10.3/storage/perfschema/pfs.cc:1869
|
#14 0x00007f02823964a4 in start_thread (arg=0x7f027a5c2700) at pthread_create.c:456
|
#15 0x00007f02804cad0f in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:97
|
Reproducible on 10.3-10.4, not on the current 10.5.
However, I find ER_KEY_NOT_FOUND to be a more serious problem here than the assertion failure.