[MDEV-22174] Assertion `cost > 0.0' failed in adjust_quick_cost Created: 2020-04-07  Updated: 2020-05-29  Resolved: 2020-05-29

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.5
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Alice Sherepa Assignee: Varun Gupta (Inactive)
Resolution: Duplicate Votes: 0
Labels: None

Issue Links:
Duplicate
is duplicated by MDEV-22191 Range access is not picked when index... Closed

 Description   

CREATE TABLE t1 (i1 int PRIMARY KEY) ENGINE=MyISAM ;
CREATE TABLE t2 (i1 int PRIMARY KEY) ENGINE=MyISAM ;
CREATE TABLE t3 (i1 int PRIMARY KEY) ENGINE=MRG_MyISAM UNION=(t1,t2) ;
SET  SESSION optimizer_switch = 'index_merge_sort_union=off';
SELECT 1 FROM t1,t3 WHERE t1.i1 = t3.i1 AND t3.i1 < 'a';

Reproducible on 10.5, with empty tables.

10.5 dcc2eaebbdf658af35

#3  <signal handler called>
#4  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#5  0x00007fbcad94b535 in __GI_abort () at abort.c:79
#6  0x00007fbcad94b40f in __assert_fail_base (fmt=0x7fbcadaadee0 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x563d6eea202e "cost > 0.0", file=0x563d6eea0e78 "/10.5/sql/sql_select.cc", line=7284, function=<optimized out>) at assert.c:92
#7  0x00007fbcad959102 in __GI___assert_fail (assertion=0x563d6eea202e "cost > 0.0", file=0x563d6eea0e78 "/10.5/sql/sql_select.cc", line=7284, function=0x563d6eea5ac0 <adjust_quick_cost(double, unsigned long long)::__PRETTY_FUNCTION__> "double adjust_quick_cost(double, ha_rows)") at assert.c:101
#8  0x0000563d6e164670 in adjust_quick_cost (quick_cost=0.14499999999999999, records=1) at /10.5/sql/sql_select.cc:7284
#9  0x0000563d6e16504e in best_access_path (join=0x7fbc980171c8, s=0x7fbc98018100, remaining_tables=2, join_positions=0x7fbc980186c8, idx=1, disable_jbuf=true, record_count=1, pos=0x7fbc980187f8, loose_scan_pos=0x7fbca830af70) at /10.5/sql/sql_select.cc:7516
#10 0x0000563d6e16ac54 in best_extension_by_limited_search (join=0x7fbc980171c8, remaining_tables=2, idx=1, record_count=1, read_time=0, search_depth=62, prune_level=1, use_cond_selectivity=4) at /10.5/sql/sql_select.cc:9537
#11 0x0000563d6e168c96 in greedy_search (join=0x7fbc980171c8, remaining_tables=2, search_depth=62, prune_level=1, use_cond_selectivity=4) at /10.5/sql/sql_select.cc:8742
#12 0x0000563d6e167f14 in choose_plan (join=0x7fbc980171c8, join_tables=2) at /10.5/sql/sql_select.cc:8307
#13 0x0000563d6e15fad1 in make_join_statistics (join=0x7fbc980171c8, tables_list=..., keyuse_array=0x7fbc980174b8) at /10.5/sql/sql_select.cc:5554
#14 0x0000563d6e153962 in JOIN::optimize_inner (this=0x7fbc980171c8) at /10.5/sql/sql_select.cc:2260
#15 0x0000563d6e151282 in JOIN::optimize (this=0x7fbc980171c8) at /10.5/sql/sql_select.cc:1606
#16 0x0000563d6e15c6cb in mysql_select (thd=0x7fbc98000d78, tables=0x7fbc980141b8, fields=..., conds=0x7fbc980158d8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fbc980171a0, unit=0x7fbc98004d80, select_lex=0x7fbc98013c60) at /10.5/sql/sql_select.cc:4654
#17 0x0000563d6e14c42a in handle_select (thd=0x7fbc98000d78, lex=0x7fbc98004cb8, result=0x7fbc980171a0, setup_tables_done_option=0) at /10.5/sql/sql_select.cc:417
#18 0x0000563d6e111c83 in execute_sqlcom_select (thd=0x7fbc98000d78, all_tables=0x7fbc980141b8) at /10.5/sql/sql_parse.cc:6168
#19 0x0000563d6e1087c2 in mysql_execute_command (thd=0x7fbc98000d78) at /10.5/sql/sql_parse.cc:3901
#20 0x0000563d6e116bb2 in mysql_parse (thd=0x7fbc98000d78, rawbuf=0x7fbc98013b90 "SELECT 1 FROM t1,t3 WHERE t1.i1 = t3.i1 AND t3.i1 < 'a'", length=55, parser_state=0x7fbca830c510, is_com_multi=false, is_next_command=false) at /10.5/sql/sql_parse.cc:7953
#21 0x0000563d6e102546 in dispatch_command (command=COM_QUERY, thd=0x7fbc98000d78, packet=0x7fbc98008d09 "SELECT 1 FROM t1,t3 WHERE t1.i1 = t3.i1 AND t3.i1 < 'a'", packet_length=55, is_com_multi=false, is_next_command=false) at /10.5/sql/sql_parse.cc:1839
#22 0x0000563d6e100c84 in do_command (thd=0x7fbc98000d78) at /10.5/sql/sql_parse.cc:1358
#23 0x0000563d6e2a24f2 in do_handle_one_connection (connect=0x563d71d15778, put_in_cache=true) at /10.5/sql/sql_connect.cc:1422
#24 0x0000563d6e2a2222 in handle_one_connection (arg=0x563d71c34c18) at /10.5/sql/sql_connect.cc:1319
#25 0x0000563d6e7d1181 in pfs_spawn_thread (arg=0x563d71d153b8) at /10.5/storage/perfschema/pfs.cc:2201
#26 0x00007fbcae3f1fa3 in start_thread (arg=<optimized out>) at pthread_create.c:486
#27 0x00007fbcada224cf in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95



 Comments   
Comment by Varun Gupta (Inactive) [ 2020-05-29 ]

This cannot be reproduced on current 10.5 but I checked on the revision dcc2eaebbdf658af35 (as reported in the description) that it is reproducible.

The bug crashes in best_access_path for a const table and an impossible range, but somehow the range optimizer is not able to tell that we have an impossible range. This is something similar to the problem encountered in MDEV-22191 and has been fixed.

Generated at Thu Feb 08 09:12:45 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.