[MDEV-31498] Assertion `(key_dependent & s->key_dependent) == key_dependent' failed in best_access_path Created: 2023-06-19  Updated: 2023-11-28

Status: Open
Project: MariaDB Server
Component/s: Data Manipulation - Subquery, Optimizer
Affects Version/s: 10.6, 10.9, 10.10, 10.11, 11.0, 11.1
Fix Version/s: 10.6, 10.11, 11.0, 11.1

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Sergei Petrunia
Resolution: Unresolved Votes: 0
Labels: None


 Description   

CREATE TABLE t (a INT PRIMARY KEY);
INSERT INTO t VALUES (1),(2);
 
REPLACE INTO t (a) SELECT t2.* FROM (SELECT a FROM t) t1 JOIN (SELECT a FROM t GROUP BY a) t2 ON t1.a = t2.a;
 
# Cleanup
DROP TABLE t;

10.6 8171f9da

mariadbd: /data/src/10.6/sql/sql_select.cc:8510: void best_access_path(JOIN*, JOIN_TAB*, table_map, const POSITION*, uint, bool, double, POSITION*, POSITION*): Assertion `(key_dependent & s->key_dependent) == key_dependent' failed.
230619 17:25:31 [ERROR] mysqld got signal 6 ;
 
#9  0x00007ff202c53df2 in __GI___assert_fail (assertion=0x55e5ce1e1160 "(key_dependent & s->key_dependent) == key_dependent", file=0x55e5ce1dbf80 "/data/src/10.6/sql/sql_select.cc", line=8510, function=0x55e5ce1e1040 "void best_access_path(JOIN*, JOIN_TAB*, table_map, const POSITION*, uint, bool, double, POSITION*, POSITION*)") at ./assert/assert.c:101
#10 0x000055e5cc27d40c in best_access_path (join=0x629000281018, s=0x62900028f918, remaining_tables=1, join_positions=0x62900028ff08, idx=0, disable_jbuf=true, record_count=1, pos=0x62900028ff08, loose_scan_pos=0x7ff1fb51ba00) at /data/src/10.6/sql/sql_select.cc:8510
#11 0x000055e5cc287818 in best_extension_by_limited_search (join=0x629000281018, remaining_tables=1, idx=0, record_count=1, read_time=0, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.6/sql/sql_select.cc:10350
#12 0x000055e5cc2834a2 in greedy_search (join=0x629000281018, remaining_tables=1, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.6/sql/sql_select.cc:9487
#13 0x000055e5cc2811b9 in choose_plan (join=0x629000281018, join_tables=1) at /data/src/10.6/sql/sql_select.cc:9047
#14 0x000055e5cc81e995 in st_join_table::choose_best_splitting (this=0x629000290aa8, idx=1, remaining_tables=2, join_positions=0x6290002910b0, spl_pd_boundary=0x7ff1fb51c500) at /data/src/10.6/sql/opt_split.cc:1080
#15 0x000055e5cc279bd5 in best_access_path (join=0x6290002818c0, s=0x629000290aa8, remaining_tables=2, join_positions=0x6290002910b0, idx=1, disable_jbuf=false, record_count=2, pos=0x6290002911f8, loose_scan_pos=0x7ff1fb51c950) at /data/src/10.6/sql/sql_select.cc:7912
#16 0x000055e5cc287818 in best_extension_by_limited_search (join=0x6290002818c0, remaining_tables=2, idx=1, record_count=2, read_time=2.3999999999999999, search_depth=61, prune_level=1, use_cond_selectivity=4) at /data/src/10.6/sql/sql_select.cc:10350
#17 0x000055e5cc28840e in best_extension_by_limited_search (join=0x6290002818c0, remaining_tables=3, idx=0, record_count=1, read_time=0, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.6/sql/sql_select.cc:10456
#18 0x000055e5cc2834a2 in greedy_search (join=0x6290002818c0, remaining_tables=3, search_depth=62, prune_level=1, use_cond_selectivity=4) at /data/src/10.6/sql/sql_select.cc:9487
#19 0x000055e5cc2811b9 in choose_plan (join=0x6290002818c0, join_tables=3) at /data/src/10.6/sql/sql_select.cc:9047
#20 0x000055e5cc26b00e in make_join_statistics (join=0x6290002818c0, tables_list=..., keyuse_array=0x629000281be8) at /data/src/10.6/sql/sql_select.cc:5977
#21 0x000055e5cc2475d0 in JOIN::optimize_inner (this=0x6290002818c0) at /data/src/10.6/sql/sql_select.cc:2529
#22 0x000055e5cc2405cb in JOIN::optimize (this=0x6290002818c0) at /data/src/10.6/sql/sql_select.cc:1868
#23 0x000055e5cc261e70 in mysql_select (thd=0x62b00007e218, tables=0x62b000087890, fields=..., conds=0x0, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2202244745984, result=0x6290002817f8, unit=0x62b000082588, select_lex=0x62b000085c50) at /data/src/10.6/sql/sql_select.cc:5069
#24 0x000055e5cc231d7e in handle_select (thd=0x62b00007e218, lex=0x62b0000824c0, result=0x6290002817f8, setup_tables_done_option=1073741824) at /data/src/10.6/sql/sql_select.cc:559
#25 0x000055e5cc18aed7 in mysql_execute_command (thd=0x62b00007e218, is_called_from_prepared_stmt=false) at /data/src/10.6/sql/sql_parse.cc:4719
#26 0x000055e5cc1a1ec5 in mysql_parse (thd=0x62b00007e218, rawbuf=0x62b000085238 "REPLACE INTO t (a) SELECT t2.* FROM (SELECT a FROM t) t1 JOIN (SELECT a FROM t GROUP BY a) t2 ON t1.a = t2.a", length=108, parser_state=0x7ff1fb51ea30) at /data/src/10.6/sql/sql_parse.cc:8036
#27 0x000055e5cc177d0c in dispatch_command (command=COM_QUERY, thd=0x62b00007e218, packet=0x62900025d219 "REPLACE INTO t (a) SELECT t2.* FROM (SELECT a FROM t) t1 JOIN (SELECT a FROM t GROUP BY a) t2 ON t1.a = t2.a", packet_length=108, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1896
#28 0x000055e5cc174a40 in do_command (thd=0x62b00007e218, blocking=true) at /data/src/10.6/sql/sql_parse.cc:1409
#29 0x000055e5cc5e1afe in do_handle_one_connection (connect=0x608000002db8, put_in_cache=true) at /data/src/10.6/sql/sql_connect.cc:1416
#30 0x000055e5cc5e14bf in handle_one_connection (arg=0x608000002d38) at /data/src/10.6/sql/sql_connect.cc:1318
#31 0x000055e5cd23e866 in pfs_spawn_thread (arg=0x617000005b98) at /data/src/10.6/storage/perfschema/pfs.cc:2201
#32 0x00007ff202ca7fd4 in start_thread (arg=<optimized out>) at ./nptl/pthread_create.c:442
#33 0x00007ff202d285bc in clone3 () at ../sysdeps/unix/sysv/linux/x86_64/clone3.S:81

Reproducible with at least MyISAM, InnoDB, Aria.
No obvious immediate problem on a non-debug build.

The failure started happening after this commit in 10.6.9:

commit 31811cf81d2d82d0260322c8c1bf7b2e046a4712
Author: Michael Widenius
Date:   Sun May 22 20:46:03 2022 +0300
 
    Make join->key_dependent up to date for derived tables
    
    Main-author: Sergei Petrunia

But the commit added the assertion which is failing, so it's unclear whether it introduced a new problem or revealed an old one.


Generated at Thu Feb 08 10:24:20 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.