[MDEV-10783] Server crashes in pushdown_cond_for_derived Created: 2016-09-09  Updated: 2016-09-23  Resolved: 2016-09-23

Status: Closed
Project: MariaDB Server
Component/s: Optimizer
Affects Version/s: 10.2
Fix Version/s: 10.2.2

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Igor Babaev
Resolution: Fixed Votes: 0
Labels: regression-10.2


 Description   

Stack trace from 10.2 1168e2fa54

#3  <signal handler called>
#4  0x00007fe1f5c0996d in pushdown_cond_for_derived (thd=0x7fe1ea416070, cond=0x7fe1ea469e50, derived=0x7fe1ea465588) at /data/src/10.2/sql/sql_derived.cc:1182
#5  0x00007fe1f5c72c71 in JOIN::optimize_inner (this=0x7fe1ea467b28) at /data/src/10.2/sql/sql_select.cc:1264
#6  0x00007fe1f5c72344 in JOIN::optimize (this=0x7fe1ea467b28) at /data/src/10.2/sql/sql_select.cc:1076
#7  0x00007fe1f5c7a798 in mysql_select (thd=0x7fe1ea416070, tables=0x7fe1ea464298, wild_num=1, fields=..., conds=0x7fe1ea465ba8, og_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=2147748608, result=0x7fe1ea467b08, unit=0x7fe1ea419b18, select_lex=0x7fe1ea41a250) at /data/src/10.2/sql/sql_select.cc:3535
#8  0x00007fe1f5c6fea1 in handle_select (thd=0x7fe1ea416070, lex=0x7fe1ea419a50, result=0x7fe1ea467b08, setup_tables_done_option=0) at /data/src/10.2/sql/sql_select.cc:373
#9  0x00007fe1f5c3f938 in execute_sqlcom_select (thd=0x7fe1ea416070, all_tables=0x7fe1ea464298) at /data/src/10.2/sql/sql_parse.cc:6345
#10 0x00007fe1f5c3576e in mysql_execute_command (thd=0x7fe1ea416070) at /data/src/10.2/sql/sql_parse.cc:3376
#11 0x00007fe1f5c430d7 in mysql_parse (thd=0x7fe1ea416070, rawbuf=0x7fe1ea464088 "SELECT * FROM t WHERE 1 IN ( SELECT * FROM v )", length=46, parser_state=0x7fe1f6b91dd0, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:7774
#12 0x00007fe1f5c314c5 in dispatch_command (command=COM_QUERY, thd=0x7fe1ea416070, packet=0x7fe1ea458071 "SELECT * FROM t WHERE 1 IN ( SELECT * FROM v )", packet_length=46, is_com_multi=false, is_next_command=false) at /data/src/10.2/sql/sql_parse.cc:1805
#13 0x00007fe1f5c2fef6 in do_command (thd=0x7fe1ea416070) at /data/src/10.2/sql/sql_parse.cc:1365
#14 0x00007fe1f5d6b7ba in do_handle_one_connection (connect=0x7fe1f286d410) at /data/src/10.2/sql/sql_connect.cc:1354
#15 0x00007fe1f5d6b547 in handle_one_connection (arg=0x7fe1f286d410) at /data/src/10.2/sql/sql_connect.cc:1260
#16 0x00007fe1f6079b26 in pfs_spawn_thread (arg=0x7fe1f28519f0) at /data/src/10.2/storage/perfschema/pfs.cc:1862
#17 0x00007fe1f52b40a4 in start_thread (arg=0x7fe1f6b93300) at pthread_create.c:309
#18 0x00007fe1f346c87d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111

CREATE TABLE t (i INT) ENGINE=MyISAM;
CREATE VIEW v AS SELECT 5;
SELECT * FROM t WHERE 1 IN ( SELECT * FROM v );

The problem started happening after recent merges, but I can't point at the exact commit which caused it.



 Comments   
Comment by Oleksandr Byelkin [ 2016-09-11 ]

It looks like problem with connecting SELECTs/UNITs.

For now it meet upper SELECT without JOIN. Taking into account how SELECTs optimizing it should not be possible...

Comment by Oleksandr Byelkin [ 2016-09-11 ]

Structure is correct. and it is pushing down. and it trying to push in SELECT which has no JOIN... (SELECT is simple maybe just removed or materialized?)

Comment by Oleksandr Byelkin [ 2016-09-11 ]

The view is already materialized and cleaned up, that is why it is has no JOIN and that is why it is too late something pushdown in it.

Comment by Oleksandr Byelkin [ 2016-09-11 ]

will discuss with igor how better to detect situation.

Comment by Igor Babaev [ 2016-09-23 ]

The fix for this bug was pushed into the 10.2 tree.

Generated at Thu Feb 08 07:44:53 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.