Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.3(EOL), 10.4(EOL), 10.5
Description
See also MDEV-18244, it probably has the same root cause. The problem described here appeared in 10.3 with the same commit that is pointed at in MDEV-18244.
--source include/have_innodb.inc
|
--source include/have_partition.inc
|
|
CREATE TABLE t1 (a INT, b INT, KEY (a)) ENGINE=InnoDB PARTITION BY KEY(b) PARTITIONS 4; |
INSERT INTO t1 VALUES (3,0),(8,2),(7,8),(3,4),(2,4),(0,7),(4,3),(3,6); |
FLUSH TABLES;
|
UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3; |
|
# Cleanup
|
DROP TABLE t1; |
10.3 55be043c13d |
#3 <signal handler called>
|
#4 0x0000556b7d49d7c3 in ha_innobase::cmp_ref (this=0x7f0aa4120ff8, ref1=0x7f0aa412f04c "", ref2=0x7f0aa412f03b "") at /data/src/10.3/storage/innobase/handler/ha_innodb.cc:16651
|
#5 0x0000556b7d8ce01e in cmp_key_rowid_part_id (ptr=0x7f0aa4120798, ref1=0x7f0aa412f041 "\003", ref2=0x7f0aa412f030 "\001") at /data/src/10.3/sql/ha_partition.cc:5553
|
#6 0x0000556b7d9102db in _downheap (queue=0x7f0aa4120cc8, start_idx=1, element=0x7f0aa412f030 "\001") at /data/src/10.3/mysys/queues.c:305
|
#7 0x0000556b7d91047a in queue_fix (queue=0x7f0aa4120cc8) at /data/src/10.3/mysys/queues.c:354
|
#8 0x0000556b7d8d4212 in ha_partition::handle_ordered_index_scan (this=0x7f0aa4120798, buf=0x7f0aa413d938 "\371\003", reverse_order=false) at /data/src/10.3/sql/ha_partition.cc:7643
|
#9 0x0000556b7d8d09ea in ha_partition::multi_range_read_next (this=0x7f0aa4120798, range_info=0x7f0ae7dfcee0) at /data/src/10.3/sql/ha_partition.cc:6480
|
#10 0x0000556b7d2dceaa in QUICK_RANGE_SELECT::get_next (this=0x7f0aa415fbe0) at /data/src/10.3/sql/opt_range.cc:11469
|
#11 0x0000556b7d2ee89a in rr_quick (info=0x7f0ae7dfd170) at /data/src/10.3/sql/records.cc:365
|
#12 0x0000556b7cdd675b in READ_RECORD::read_record (this=0x7f0ae7dfd170) at /data/src/10.3/sql/records.h:73
|
#13 0x0000556b7cf69feb in mysql_update (thd=0x7f0aa4000b00, table_list=0x7f0aa4014e70, fields=..., values=..., conds=0x7f0aa4015850, order_num=0, order=0x0, limit=18446744073709551615, handle_duplicates=DUP_ERROR, ignore=false, found_return=0x7f0ae7dfd6f0, updated_return=0x7f0ae7dfd7b0) at /data/src/10.3/sql/sql_update.cc:739
|
#14 0x0000556b7ce72221 in mysql_execute_command (thd=0x7f0aa4000b00) at /data/src/10.3/sql/sql_parse.cc:4581
|
#15 0x0000556b7ce7d63d in mysql_parse (thd=0x7f0aa4000b00, rawbuf=0x7f0aa4014cd8 "UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3", length=49, parser_state=0x7f0ae7dfe5f0, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:8092
|
#16 0x0000556b7ce6a7f1 in dispatch_command (command=COM_QUERY, thd=0x7f0aa4000b00, packet=0x7f0aa400b1e1 "UPDATE t1 PARTITION (p3,p1) SET a = 2 WHERE a = 3", packet_length=49, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1851
|
#17 0x0000556b7ce69215 in do_command (thd=0x7f0aa4000b00) at /data/src/10.3/sql/sql_parse.cc:1396
|
#18 0x0000556b7cfd122a in do_handle_one_connection (connect=0x556b8097b9e0) at /data/src/10.3/sql/sql_connect.cc:1402
|
#19 0x0000556b7cfd0fae in handle_one_connection (arg=0x556b8097b9e0) at /data/src/10.3/sql/sql_connect.cc:1308
|
#20 0x0000556b7d46b89f in pfs_spawn_thread (arg=0x556b80992780) at /data/src/10.3/storage/perfschema/pfs.cc:1862
|
#21 0x00007f0af47c3494 in start_thread (arg=0x7f0ae7dff700) at pthread_create.c:333
|
#22 0x00007f0af2ba993f in clone () from /lib/x86_64-linux-gnu/libc.so.6
|
All of debug, ASAN and non-debug builds fail the same way.
There is initial analysis by marko in a comment to MDEV-18244.