Details
Major
Description
#3 <signal handler called> #4 0x00000000006349f3 in Item_in_subselect::optimize (this=0x2a83fe8, out_rows=0x7f6cd018e930, cost=0x7f6cd018e928) at item_subselect.cc:616 #5 0x000000000081916e in setup_jtbm_semi_joins (join=0x2a4cc60, join_list=0x2a81150, join_where=0x2a4d048) at opt_subselect.cc:5109 #6 0x000000000072826b in JOIN::optimize (this=0x2a4cc60) at sql_select.cc:1024 #7 0x000000000072f4b7 in mysql_select (thd=0x29c8bc8, rref_pointer_array=0x2a81238, tables=0x2a81d80, wild_num=0, fields=..., conds=0x2a4ca50, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2416200192, result=0x2a843b8, unit=0x2a80ad8, select_lex=0x2a80fe0) at sql_select.cc:2995 #8 0x0000000000725fad in handle_select (thd=0x29c8bc8, lex=0x2a80a38, result=0x2a843b8, setup_tables_done_option=0) at sql_select.cc:288 #9 0x00000000006b4ca8 in execute_sqlcom_select (thd=0x29c8bc8, all_tables=0x2a81d80) at sql_parse.cc:5172 #10 0x00000000006abe44 in mysql_execute_command (thd=0x29c8bc8) at sql_parse.cc:2305 #11 0x0000000000786fee in Prepared_statement::execute (this=0x2a80668, expanded_query=0x7f6cd018fcb0, open_cursor=false) at sql_prepare.cc:3764 #12 0x000000000078623b in Prepared_statement::execute_loop (this=0x2a80668, expanded_query=0x7f6cd018fcb0, open_cursor=false, packet=0x0, packet_end=0x0) at sql_prepare.cc:3445 #13 0x0000000000784692 in mysql_sql_stmt_execute (thd=0x29c8bc8) at sql_prepare.cc:2670 #14 0x00000000006abe72 in mysql_execute_command (thd=0x29c8bc8) at sql_parse.cc:2314 #15 0x00000000006b760f in mysql_parse (thd=0x29c8bc8, rawbuf=0x2a4c900 "EXECUTE stmt", length=12, found_semicolon=0x7f6cd0190cb8) at sql_parse.cc:6173 #16 0x00000000006a9624 in dispatch_command (command=COM_QUERY, thd=0x29c8bc8, packet=0x2a43499 "EXECUTE stmt", packet_length=12) at sql_parse.cc:1243 #17 0x00000000006a8910 in do_command (thd=0x29c8bc8) at sql_parse.cc:923 #18 0x00000000006a5799 in handle_one_connection (arg=0x29c8bc8) at sql_connect.cc:1231 #19 0x00007f6cd997fb50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #20 0x00007f6cd8d22a7d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
revision-id: psergey@askmonty.org-20131127134316-ljkto7w7f41oddrk revno: 3728 branch-nick: 5.3 BUILD/compile-pentium-debug-max-no-ndb
SET optimizer_switch = 'materialization=on,semijoin=on'; CREATE TABLE t1 (a INT) ENGINE=MyISAM; INSERT INTO t1 VALUES (1),(3); CREATE TABLE t2 (b INT) ENGINE=MyISAM; CREATE ALGORITHM=MERGE VIEW v2 AS SELECT * FROM t2; INSERT INTO t2 VALUES (8),(9); PREPARE stmt FROM " SELECT * FROM t1 WHERE 1 IN ( SELECT b FROM v2 WHERE 2 IN ( SELECT MAX(a) FROM t1 ) ) "; EXECUTE stmt; EXECUTE stmt;
Gliffy Diagrams
Attachments
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
convert_subq_to_jtbm() has these lines:
/* Nests do not participate in those 'chains', so: */
/* jtbm->next_leaf= jtbm->next_local= jtbm->next_global == NULL*/
...
/* A theory: no need to re-connect the next_global chain */
Perhaps, they are the cause of this bug.
The code actually makes an attempt to connect the next_leaf chain. The problem is that something is connected in the wrong place.
Debugging, I see:
- non-merged-semi-join table is connected to a list with 'v'.
- top-level select initially has only "t1a" in the list.
then "t2" is connected to it.
that way, second re-execution doesn't see the non-merged semi-join in TABLE_LIST::next_local chain
Had a discussion with Sanja. convert_subq_to_sj() has this code
tl->next_local= subq_lex->leaf_tables.head();
it attaches first of child's leaf_tables into the parent's TABLE_LIST:::next_local list. This is incorrect, we should attach child's next_local chain (and not the first table in child's leaf_tables list).
a VIEW is not necessary, the crash could be repeated when using a derived table, too:
prepare s from '
SELECT * FROM t1 WHERE 1 IN ( SELECT b FROM (SELECT * FROM t2) v2 WHERE 2 IN (
SELECT MAX(a) FROM t1 ) )';
execute s;
execute s;