Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.2, 10.3, 10.4, 10.5, 10.6
-
None
Description
On some reason I cannot get rid of concurrency between DELETE and INSERT in the test case. The test fails every time for me, which hints at some predictable execution of DELETE and INSERT, and yet I can't serialize them in any order. If I remove the concurrency, everything starts working as expected, SELECT .. FOR UPDATE ending with a timeout.
--source include/have_innodb.inc
|
|
|
CREATE TABLE t1 (pk INT, a INT, b INT, PRIMARY KEY (pk), KEY (a,b)) ENGINE=InnoDB; |
INSERT INTO t1 (pk,a) VALUES (1,11),(2,12),(3,13),(4,14); |
|
|
--connect (con1,localhost,root,,)
|
--send
|
DELETE FROM t1 WHERE pk <= 3; |
|
|
--connection default
|
INSERT INTO t1 (pk) VALUES (5); |
|
|
--connection con1
|
--reap
|
|
|
START TRANSACTION; |
INSERT INTO t1 (pk) VALUES (6); |
|
|
--connection default
|
SET lock_wait_timeout= 1, innodb_lock_wait_timeout= 1; |
--error ER_LOCK_WAIT_TIMEOUT
|
SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE; |
|
|
# Cleanup
|
--connection con1
|
COMMIT; |
DROP TABLE t1; |
--disconnect con1 |
|
10.2 cd1a195b |
mysqld: /data/src/10.2/sql/opt_range.cc:14117: virtual int QUICK_GROUP_MIN_MAX_SELECT::get_next(): Assertion `(have_max && !have_min) || (have_max && have_min && (max_res == 0))' failed.
|
210618 16:12:47 [ERROR] mysqld got signal 6 ;
|
|
|
#7 0x00007fd74b0ebf36 in __GI___assert_fail (assertion=0x5565c746b3e8 "(have_max && !have_min) || (have_max && have_min && (max_res == 0))", file=0x5565c74696f8 "/data/src/10.2/sql/opt_range.cc", line=14117, function=0x5565c746b3a0 "virtual int QUICK_GROUP_MIN_MAX_SELECT::get_next()") at assert.c:101
|
#8 0x00005565c6ce247f in QUICK_GROUP_MIN_MAX_SELECT::get_next (this=0x7fd6f0182bf0) at /data/src/10.2/sql/opt_range.cc:14117
|
#9 0x00005565c6cedd11 in rr_quick (info=0x7fd6f00150d0) at /data/src/10.2/sql/records.cc:373
|
#10 0x00005565c6962ced in join_init_read_record (tab=0x7fd6f0015008) at /data/src/10.2/sql/sql_select.cc:19794
|
#11 0x00005565c6960a2c in sub_select (join=0x7fd6f00136a0, join_tab=0x7fd6f0015008, end_of_records=false) at /data/src/10.2/sql/sql_select.cc:18865
|
#12 0x00005565c695fff0 in do_select (join=0x7fd6f00136a0, procedure=0x0) at /data/src/10.2/sql/sql_select.cc:18412
|
#13 0x00005565c6939c0d in JOIN::exec_inner (this=0x7fd6f00136a0) at /data/src/10.2/sql/sql_select.cc:3651
|
#14 0x00005565c69390b4 in JOIN::exec (this=0x7fd6f00136a0) at /data/src/10.2/sql/sql_select.cc:3446
|
#15 0x00005565c693a28e in mysql_select (thd=0x7fd6f0000d90, tables=0x7fd6f0012e30, wild_num=0, fields=..., conds=0x0, og_num=1, order=0x0, group=0x7fd6f0013570, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fd6f0013680, unit=0x7fd6f0004988, select_lex=0x7fd6f00050d8) at /data/src/10.2/sql/sql_select.cc:3849
|
#16 0x00005565c692e3e2 in handle_select (thd=0x7fd6f0000d90, lex=0x7fd6f00048c8, result=0x7fd6f0013680, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:361
|
#17 0x00005565c68f8ad6 in execute_sqlcom_select (thd=0x7fd6f0000d90, all_tables=0x7fd6f0012e30) at /data/src/10.2/sql/sql_parse.cc:6271
|
#18 0x00005565c68ef64a in mysql_execute_command (thd=0x7fd6f0000d90) at /data/src/10.2/sql/sql_parse.cc:3582
|
#19 0x00005565c68fc892 in mysql_parse (thd=0x7fd6f0000d90, rawbuf=0x7fd6f0012708 "SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE", length=54, parser_state=0x7fd745407560, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7793
|
#20 0x00005565c68eaaed in dispatch_command (command=COM_QUERY, thd=0x7fd6f0000d90, packet=0x7fd6f0008b61 "", packet_length=54, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1827
|
#21 0x00005565c68e95e8 in do_command (thd=0x7fd6f0000d90) at /data/src/10.2/sql/sql_parse.cc:1381
|
#22 0x00005565c6a44a6b in do_handle_one_connection (connect=0x5565c99a9a40) at /data/src/10.2/sql/sql_connect.cc:1336
|
#23 0x00005565c6a447d0 in handle_one_connection (arg=0x5565c99a9a40) at /data/src/10.2/sql/sql_connect.cc:1241
|
#24 0x00005565c7270bec in pfs_spawn_thread (arg=0x5565c9a4cc90) at /data/src/10.2/storage/perfschema/pfs.cc:1869
|
#25 0x00007fd74b5fb609 in start_thread (arg=<optimized out>) at pthread_create.c:477
|
#26 0x00007fd74b1d7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
|
Reproducible on 10.2-10.6 debug builds.
Non-debug builds also behave in a strange way. SELECT .. FOR UPDATE stops waiting for a lock as it should, but after the timeout is exceeded, instead of failing it proceeds and returns a result.
select now(6); |
now(6)
|
2021-06-18 16:15:49.561749
|
SELECT MIN(b), MAX(b), a FROM t1 GROUP BY a FOR UPDATE; |
MIN(b) MAX(b) a |
NULL NULL NULL |
NULL NULL 14 |
select now(6); |
now(6)
|
2021-06-18 16:15:51.477560
|