|
In the testcase below, INSERT INTO s1 used to be failing with ER_LOCK_WAIT_TIMEOUT. Now it doesn't (on a release build), but instead the concurrent SELECT fails with an assertion failure on a debug build.
CREATE SEQUENCE s1;
|
CREATE SEQUENCE s2;
|
|
--connect (con1,localhost,root,,)
|
SET SESSION TRANSACTION READ ONLY;
|
START TRANSACTION;
|
|
--connection default
|
START TRANSACTION;
|
INSERT INTO s2 VALUES (1, 1, 10000, 100, 1, 1000, 0, 0);
|
|
--connection con1
|
SELECT LASTVAL(s1);
|
--send
|
SELECT LASTVAL(s2);
|
|
--connection default
|
SET lock_wait_timeout= 1;
|
#--error ER_LOCK_WAIT_TIMEOUT
|
INSERT INTO s1 VALUES (1, 1, 10000, 100, 1, 1000, 0, 0);
|
|
# Cleanup
|
--connection con1
|
--error ER_LOCK_DEADLOCK
|
--reap
|
--disconnect con1
|
--connection default
|
DROP SEQUENCE s1;
|
DROP SEQUENCE s2;
|
|
10.4 7d89dcf1
|
mysqld: /data/src/10.4/sql/mdl.cc:3105: void MDL_context::release_transactional_locks(THD*): Assertion `!(thd->server_status & (1U | 8192U))' failed.
|
231021 19:35:43 [ERROR] mysqld got signal 6 ;
|
|
#9 0x00007f9d51e53df2 in __GI___assert_fail (assertion=0x560016456e00 "!(thd->server_status & (1U | 8192U))", file=0x560016454800 "/data/src/10.4/sql/mdl.cc", line=3105, function=0x560016456da0 "void MDL_context::release_transactional_locks(THD*)") at ./assert/assert.c:101
|
#10 0x00005600146a8e5e in MDL_context::release_transactional_locks (this=0x62b00008c350, thd=0x62b00008c208) at /data/src/10.4/sql/mdl.cc:3105
|
#11 0x0000560014063875 in THD::release_transactional_locks (this=0x62b00008c208) at /data/src/10.4/sql/sql_class.h:4699
|
#12 0x00005600142a284c in mysql_execute_command (thd=0x62b00008c208) at /data/src/10.4/sql/sql_parse.cc:6305
|
#13 0x00005600142ad5bd in mysql_parse (thd=0x62b00008c208, rawbuf=0x62b000093228 "SELECT LASTVAL(s2)", length=18, parser_state=0x7f9d49e8d860, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:8012
|
#14 0x000056001428384c in dispatch_command (command=COM_QUERY, thd=0x62b00008c208, packet=0x62900023f209 "SELECT LASTVAL(s2)", packet_length=18, is_com_multi=false, is_next_command=false) at /data/src/10.4/sql/sql_parse.cc:1857
|
#15 0x00005600142803bb in do_command (thd=0x62b00008c208) at /data/src/10.4/sql/sql_parse.cc:1378
|
#16 0x000056001467fee2 in do_handle_one_connection (connect=0x608000000aa8) at /data/src/10.4/sql/sql_connect.cc:1420
|
#17 0x000056001467f7f9 in handle_one_connection (arg=0x608000000aa8) at /data/src/10.4/sql/sql_connect.cc:1324
|
#18 0x00005600152f154a in pfs_spawn_thread (arg=0x615000003c88) at /data/src/10.4/storage/perfschema/pfs.cc:1869
|
#19 0x00007f9d51ea7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
|
#20 0x00007f9d51f285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81
|
The failure started happening after this commit in 10.4:
commit f293b2b21149e9085bee8ecdc5ee627233830eb0
|
Author: Sergei Golubchik
|
Date: Mon Oct 16 14:29:12 2023 +0200
|
|
cleanup
|
|