[MDEV-14565] Assertion `partition_id == m_extra_cache_part_id' failed in ha_partition::late_extra_no_cache Created: 2017-12-04  Updated: 2017-12-12  Resolved: 2017-12-12

Status: Closed
Project: MariaDB Server
Component/s: Partitioning
Affects Version/s: 10.3
Fix Version/s: 10.3.3

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Michael Widenius
Resolution: Fixed Votes: 0
Labels: regression


 Description   

--source include/have_partition.inc
 
CREATE TABLE t1 (f1 INT, f2 INT, f3 INT, f4 INT, KEY (f4), 
  KEY (f1,f4,f3,f2)
) PARTITION BY RANGE(f1) ( PARTITION p VALUES LESS THAN MAXVALUE );
INSERT IGNORE INTO t1 VALUES 
(140,0,0,7),(143,92,NULL,0),(0,0,NULL,154),(NULL,255,117,197),(0,0,NULL,0),(60,0,0,1);
 
CREATE TABLE t2 (f INT);
INSERT INTO t2 VALUES (NULL),(35),(NULL),(2);
 
SELECT * FROM t1, t2 WHERE f4 >= f;
 
# Cleanup
DROP TABLE t1, t2;

10.3 60df17e95ad72 debug

mysqld: /data/src/10.3/sql/ha_partition.cc:9007: void ha_partition::late_extra_no_cache(uint): Assertion `partition_id == m_extra_cache_part_id' failed.
171204 14:56:25 [ERROR] mysqld got signal 6 ;
 
#7  0x00007fcde0840ee2 in __assert_fail () from /lib/x86_64-linux-gnu/libc.so.6
#8  0x000055bbdfc38d4f in ha_partition::late_extra_no_cache (this=0x7fcdc80aed88, partition_id=0) at /data/src/10.3/sql/ha_partition.cc:9007
#9  0x000055bbdfc2ea53 in ha_partition::rnd_end (this=0x7fcdc80aed88) at /data/src/10.3/sql/ha_partition.cc:4964
#10 0x000055bbdfc2e80e in ha_partition::rnd_init (this=0x7fcdc80aed88, scan=true) at /data/src/10.3/sql/ha_partition.cc:4906
#11 0x000055bbdf1428c1 in handler::ha_rnd_init (this=0x7fcdc80aed88, scan=true) at /data/src/10.3/sql/handler.h:2904
#12 0x000055bbdf49cf2b in handler::ha_rnd_init_with_error (this=0x7fcdc80aed88, scan=true) at /data/src/10.3/sql/handler.cc:2801
#13 0x000055bbdf61269f in init_read_record (info=0x7fcdc8018658, thd=0x7fcdc8000b00, table=0x7fcdc80ae160, select=0x7fcdc8018ee0, filesort=0x0, use_record_cache=1, print_error=true, disable_rr_cache=false) at /data/src/10.3/sql/records.cc:299
#14 0x000055bbdf241cee in join_init_read_record (tab=0x7fcdc8018590) at /data/src/10.3/sql/sql_select.cc:19923
#15 0x000055bbdf2418de in join_init_quick_read_record (tab=0x7fcdc8018590) at /data/src/10.3/sql/sql_select.cc:19858
#16 0x000055bbdf23fad0 in sub_select (join=0x7fcdc8015e58, join_tab=0x7fcdc8018590, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:19000
#17 0x000055bbdf24021b in evaluate_join_record (join=0x7fcdc8015e58, join_tab=0x7fcdc80181e0, error=0) at /data/src/10.3/sql/sql_select.cc:19223
#18 0x000055bbdf23fcbf in sub_select (join=0x7fcdc8015e58, join_tab=0x7fcdc80181e0, end_of_records=false) at /data/src/10.3/sql/sql_select.cc:19042
#19 0x000055bbdf23f09b in do_select (join=0x7fcdc8015e58, procedure=0x0) at /data/src/10.3/sql/sql_select.cc:18543
#20 0x000055bbdf2179ee in JOIN::exec_inner (this=0x7fcdc8015e58) at /data/src/10.3/sql/sql_select.cc:3624
#21 0x000055bbdf216e86 in JOIN::exec (this=0x7fcdc8015e58) at /data/src/10.3/sql/sql_select.cc:3419
#22 0x000055bbdf218067 in mysql_select (thd=0x7fcdc8000b00, tables=0x7fcdc8014d48, wild_num=1, fields=..., conds=0x7fcdc8015bf0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fcdc8015e38, unit=0x7fcdc8004818, select_lex=0x7fcdc8004f50) at /data/src/10.3/sql/sql_select.cc:3819
#23 0x000055bbdf20c166 in handle_select (thd=0x7fcdc8000b00, lex=0x7fcdc8004750, result=0x7fcdc8015e38, setup_tables_done_option=0) at /data/src/10.3/sql/sql_select.cc:378
#24 0x000055bbdf1d79e0 in execute_sqlcom_select (thd=0x7fcdc8000b00, all_tables=0x7fcdc8014d48) at /data/src/10.3/sql/sql_parse.cc:6503
#25 0x000055bbdf1ce143 in mysql_execute_command (thd=0x7fcdc8000b00) at /data/src/10.3/sql/sql_parse.cc:3748
#26 0x000055bbdf1db314 in mysql_parse (thd=0x7fcdc8000b00, rawbuf=0x7fcdc8014b38 "SELECT * FROM t1, t2 WHERE f4 >= f", length=34, parser_state=0x7fcddaaaf610, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:7959
#27 0x000055bbdf1c8c50 in dispatch_command (command=COM_QUERY, thd=0x7fcdc8000b00, packet=0x7fcdc813d8d1 "", packet_length=34, is_com_multi=false, is_next_command=false) at /data/src/10.3/sql/sql_parse.cc:1828
#28 0x000055bbdf1c7671 in do_command (thd=0x7fcdc8000b00) at /data/src/10.3/sql/sql_parse.cc:1370
#29 0x000055bbdf31ff7a in do_handle_one_connection (connect=0x55bbe1ea1ad0) at /data/src/10.3/sql/sql_connect.cc:1420
#30 0x000055bbdf31fd07 in handle_one_connection (arg=0x55bbe1ea1ad0) at /data/src/10.3/sql/sql_connect.cc:1326
#31 0x000055bbdf7a5f4e in pfs_spawn_thread (arg=0x55bbe1f425d0) at /data/src/10.3/storage/perfschema/pfs.cc:1863
#32 0x00007fcde2517494 in start_thread (arg=0x7fcddaab0700) at pthread_create.c:333
#33 0x00007fcde08fd93f in clone () from /lib/x86_64-linux-gnu/libc.so.6

The failure appeared after the spider merge.



 Comments   
Comment by Michael Widenius [ 2017-12-12 ]

This happens because of the new code in the partition engine that can handle
multi_range_reads.

The problem was that multi_range_read_info_const() called
multi_range_key_create_key() which changed m_part_spec.start_part,
while there was an activ table scan ongoing.

Fixed by copying and restoring m_part_spec around
multi_range_key_create_calls()

Generated at Thu Feb 08 08:14:34 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.