[MDEV-10972] Insert from select / view / union -- repeatable crash in 10.1, 10.2 Linux/Mac/Windows - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Major
Resolution: Fixed
Affects Version/s: 10.1.18, 10.2.1, 10.1(EOL), 10.2(EOL)
Fix Version/s: 10.1.27, 10.2.9, 10.3.2
Component/s: Optimizer
Labels:
None
Environment:
Centos 7 AWS but also Sierra and Windows 10

Sprint:
10.1.19, 10.2.4-1, 10.2.4-2

Description

I've hit what appears to be an optimizer bug that crashes the server daemon. The test case works fine on 10.0.x but fails on 10.1.18 and 10.2.1.

Attachments

Issue Links

is duplicated by

MDEV-13174 Repeatable daemon crash in 10.2.6 on show procedure / select sql_derived.cc:1081

Closed

MDEV-13365 Crash when select where not in select distinct subquery

Closed

relates to

MDEV-13174 Repeatable daemon crash in 10.2.6 on show procedure / select sql_derived.cc:1081

Closed

Activity

Ascending order - Click to sort in descending order

Michael Newcomb created issue - 2016-10-06 20:47

Michael Newcomb added a comment - 2016-10-06 20:55

Uploaded test case data to ftp.askmonty.org/private/~~MDEV-10972~~.zip.

Steps I use to reproduce the error:

Spin up a brand new AWS Centos7 instance (micro)
Follow mariadb directions to install 10.1.18 using yum
Load the test data:

mysql --user=root --password=(password) --comments < mdbug.sql

This should create a test database. To cause the crash run the provoke shell script or:

mysql --verbose --user=mdbug --password=mdbug --database=mdbug < provoke.sql

This causes a crash 100% of the time for me. The Zip file includes server.cnf and the log files from my test instance.

The same code runs fine on 10.0.27.

If there's anything I can do to help please let me know...

Thanks for your help!

Michael Newcomb added a comment - 2016-10-06 20:55 Uploaded test case data to ftp.askmonty.org/private/ MDEV-10972 .zip. Steps I use to reproduce the error: Spin up a brand new AWS Centos7 instance (micro) Follow mariadb directions to install 10.1.18 using yum Load the test data: mysql --user=root --password=(password) --comments < mdbug.sql This should create a test database. To cause the crash run the provoke shell script or: mysql --verbose --user=mdbug --password=mdbug --database=mdbug < provoke.sql This causes a crash 100% of the time for me. The Zip file includes server.cnf and the log files from my test instance. The same code runs fine on 10.0.27. If there's anything I can do to help please let me know... Thanks for your help!

Michael Newcomb made changes - 2016-10-06 21:00

Field	Original Value	New Value
Summary	Repeatable crash in 10.1, 10.2 Linux/Mac/Windows	Insert from select / view / union -- repeatable crash in 10.1, 10.2 Linux/Mac/Windows

Michael Newcomb added a comment - 2016-10-06 21:01

Offending statement looks like this:

insert into acct_update

    account_name, account_display_name, account_desc,

    hubspotter_id

select a.account_name, a.account_display_name, a.account_desc,

	a.hubspotter_id

from

    select account_id

    from v_pacgroup_accounts

    union

    select account_id

    from v_pacgroup_special

) guu

inner join accounts a on

	(guu.account_id = a.account_id)

Michael Newcomb added a comment - 2016-10-06 21:01 Offending statement looks like this: insert into acct_update ( account_name, account_display_name, account_desc, hubspotter_id ) select a.account_name, a.account_display_name, a.account_desc, a.hubspotter_id from ( select account_id from v_pacgroup_accounts union select account_id from v_pacgroup_special ) guu inner join accounts a on (guu.account_id = a.account_id)

Elena Stepanova made changes - 2016-10-07 13:22

Status

Open [ 1 ]

Confirmed [ 10101 ]

Elena Stepanova added a comment - 2016-10-07 13:23

Stack trace from 10.1 f35e918989080d1810c2e1c7fc91f3130585607b
#3 <signal handler called>
#4 0x000055d2ab7e2e32 in Time_and_counter_tracker::incr_loops (this=0x78) at /home/elenst/10.1/sql/sql_analyze_stmt.h:97
#5 0x000055d2ab7a6655 in JOIN::exec (this=0x7f400a02e9e0) at /home/elenst/10.1/sql/sql_select.cc:2503
#6 0x000055d2ab83d092 in st_select_lex_unit::exec (this=0x7f400e1a2f60) at /home/elenst/10.1/sql/sql_union.cc:832
#7 0x000055d2ab73aeec in mysql_derived_fill (thd=0x7f4013271070, lex=0x7f400e19f1e8, derived=0x7f400e1a5298) at /home/elenst/10.1/sql/sql_derived.cc:918
#8 0x000055d2ab739945 in mysql_handle_single_derived (lex=0x7f400e19f1e8, derived=0x7f400e1a5298, phases=96) at /home/elenst/10.1/sql/sql_derived.cc:195
#9 0x000055d2ab7bf151 in st_join_table::preread_init (this=0x7f400a0cc8f0) at /home/elenst/10.1/sql/sql_select.cc:11698
#10 0x000055d2ab7ce843 in sub_select (join=0x7f400a02f6d0, join_tab=0x7f400a0cc8f0, end_of_records=false) at /home/elenst/10.1/sql/sql_select.cc:18282
#11 0x000055d2ab7cf0d7 in evaluate_join_record (join=0x7f400a02f6d0, join_tab=0x7f400a0cc5a8, error=0) at /home/elenst/10.1/sql/sql_select.cc:18539
#12 0x000055d2ab7ce9e1 in sub_select (join=0x7f400a02f6d0, join_tab=0x7f400a0cc5a8, end_of_records=false) at /home/elenst/10.1/sql/sql_select.cc:18314
#13 0x000055d2ab7ce257 in do_select (join=0x7f400a02f6d0, fields=0x7f400e19fac8, table=0x0, procedure=0x0) at /home/elenst/10.1/sql/sql_select.cc:17969
#14 0x000055d2ab7a93ff in JOIN::exec_inner (this=0x7f400a02f6d0) at /home/elenst/10.1/sql/sql_select.cc:3215
#15 0x000055d2ab7a66ab in JOIN::exec (this=0x7f400a02f6d0) at /home/elenst/10.1/sql/sql_select.cc:2505
#16 0x000055d2ab7a9c11 in mysql_select (thd=0x7f4013271070, rref_pointer_array=0x7f400e19fc28, tables=0x7f400e1a5298, wild_num=0, fields=..., conds=0x0, og
_num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3498839552, result=0x7f400a02f630, unit=0x7f400e19f2b0, select_lex=0x7f400e19f9b0)
at /home/elenst/10.1/sql/sql_select.cc:3438
#17 0x000055d2ab79f727 in handle_select (thd=0x7f4013271070, lex=0x7f400e19f1e8, result=0x7f400a02f630, setup_tables_done_option=1073741824) at /home/elenst/10.1/sql/sql_select.cc:384
#18 0x000055d2ab768449 in mysql_execute_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:4003
#19 0x000055d2abaeff6c in sp_instr_stmt::exec_core (this=0x7f400e1a5fa8, thd=0x7f4013271070, nextp=0x7f403951c674) at /home/elenst/10.1/sql/sp_head.cc:3215
#20 0x000055d2abaef6a2 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f400e1a5fe8, thd=0x7f4013271070, nextp=0x7f403951c674, open_tables=false, instr=0x7f400e1a5fa8) at /home/elenst/10.1/sql/sp_head.cc:2981
#21 0x000055d2abaefc6c in sp_instr_stmt::execute (this=0x7f400e1a5fa8, thd=0x7f4013271070, nextp=0x7f403951c674) at /home/elenst/10.1/sql/sp_head.cc:3131
#22 0x000055d2abaeb541 in sp_head::execute (this=0x7f400e23d088, thd=0x7f4013271070, merge_da_on_success=true) at /home/elenst/10.1/sql/sp_head.cc:1319
#23 0x000055d2abaed3d2 in sp_head::execute_procedure (this=0x7f400e23d088, thd=0x7f4013271070, args=0x7f4013275710) at /home/elenst/10.1/sql/sp_head.cc:2106
#24 0x000055d2ab763b0d in do_execute_sp (thd=0x7f4013271070, sp=0x7f400e23d088) at /home/elenst/10.1/sql/sql_parse.cc:2403
#25 0x000055d2ab76ce0f in mysql_execute_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:5254
#26 0x000055d2ab772eef in mysql_parse (thd=0x7f4013271070, rawbuf=0x7f400b7f7088 "CALL p_update_ccs_system(122)", length=29, parser_state=0x7f403951d630) at /home/elenst/10.1/sql/sql_parse.cc:7318
#27 0x000055d2ab7615f3 in dispatch_command (command=COM_QUERY, thd=0x7f4013271070, packet=0x7f4013297071 "CALL p_update_ccs_system(122)", packet_length=29) at /home/elenst/10.1/sql/sql_parse.cc:1487
#28 0x000055d2ab760323 in do_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:1108
#29 0x000055d2ab896719 in do_handle_one_connection (thd_arg=0x7f4013271070) at /home/elenst/10.1/sql/sql_connect.cc:1350
#30 0x000055d2ab896468 in handle_one_connection (arg=0x7f4013271070) at /home/elenst/10.1/sql/sql_connect.cc:1262
#31 0x00007f4037e146fa in start_thread (arg=0x7f403951eb00) at pthread_create.c:333
#32 0x00007f40374bfb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Elena Stepanova added a comment - 2016-10-07 13:23 Stack trace from 10.1 f35e918989080d1810c2e1c7fc91f3130585607b #3 <signal handler called> #4 0x000055d2ab7e2e32 in Time_and_counter_tracker::incr_loops (this=0x78) at /home/elenst/10.1/sql/sql_analyze_stmt.h:97 #5 0x000055d2ab7a6655 in JOIN::exec (this=0x7f400a02e9e0) at /home/elenst/10.1/sql/sql_select.cc:2503 #6 0x000055d2ab83d092 in st_select_lex_unit::exec (this=0x7f400e1a2f60) at /home/elenst/10.1/sql/sql_union.cc:832 #7 0x000055d2ab73aeec in mysql_derived_fill (thd=0x7f4013271070, lex=0x7f400e19f1e8, derived=0x7f400e1a5298) at /home/elenst/10.1/sql/sql_derived.cc:918 #8 0x000055d2ab739945 in mysql_handle_single_derived (lex=0x7f400e19f1e8, derived=0x7f400e1a5298, phases=96) at /home/elenst/10.1/sql/sql_derived.cc:195 #9 0x000055d2ab7bf151 in st_join_table::preread_init (this=0x7f400a0cc8f0) at /home/elenst/10.1/sql/sql_select.cc:11698 #10 0x000055d2ab7ce843 in sub_select (join=0x7f400a02f6d0, join_tab=0x7f400a0cc8f0, end_of_records=false) at /home/elenst/10.1/sql/sql_select.cc:18282 #11 0x000055d2ab7cf0d7 in evaluate_join_record (join=0x7f400a02f6d0, join_tab=0x7f400a0cc5a8, error=0) at /home/elenst/10.1/sql/sql_select.cc:18539 #12 0x000055d2ab7ce9e1 in sub_select (join=0x7f400a02f6d0, join_tab=0x7f400a0cc5a8, end_of_records=false) at /home/elenst/10.1/sql/sql_select.cc:18314 #13 0x000055d2ab7ce257 in do_select (join=0x7f400a02f6d0, fields=0x7f400e19fac8, table=0x0, procedure=0x0) at /home/elenst/10.1/sql/sql_select.cc:17969 #14 0x000055d2ab7a93ff in JOIN::exec_inner (this=0x7f400a02f6d0) at /home/elenst/10.1/sql/sql_select.cc:3215 #15 0x000055d2ab7a66ab in JOIN::exec (this=0x7f400a02f6d0) at /home/elenst/10.1/sql/sql_select.cc:2505 #16 0x000055d2ab7a9c11 in mysql_select (thd=0x7f4013271070, rref_pointer_array=0x7f400e19fc28, tables=0x7f400e1a5298, wild_num=0, fields=..., conds=0x0, og _num=0, order=0x0, group=0x0, having=0x0, proc_param=0x0, select_options=3498839552, result=0x7f400a02f630, unit=0x7f400e19f2b0, select_lex=0x7f400e19f9b0) at /home/elenst/10.1/sql/sql_select.cc:3438 #17 0x000055d2ab79f727 in handle_select (thd=0x7f4013271070, lex=0x7f400e19f1e8, result=0x7f400a02f630, setup_tables_done_option=1073741824) at /home/elenst/10.1/sql/sql_select.cc:384 #18 0x000055d2ab768449 in mysql_execute_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:4003 #19 0x000055d2abaeff6c in sp_instr_stmt::exec_core (this=0x7f400e1a5fa8, thd=0x7f4013271070, nextp=0x7f403951c674) at /home/elenst/10.1/sql/sp_head.cc:3215 #20 0x000055d2abaef6a2 in sp_lex_keeper::reset_lex_and_exec_core (this=0x7f400e1a5fe8, thd=0x7f4013271070, nextp=0x7f403951c674, open_tables=false, instr=0x7f400e1a5fa8) at /home/elenst/10.1/sql/sp_head.cc:2981 #21 0x000055d2abaefc6c in sp_instr_stmt::execute (this=0x7f400e1a5fa8, thd=0x7f4013271070, nextp=0x7f403951c674) at /home/elenst/10.1/sql/sp_head.cc:3131 #22 0x000055d2abaeb541 in sp_head::execute (this=0x7f400e23d088, thd=0x7f4013271070, merge_da_on_success=true) at /home/elenst/10.1/sql/sp_head.cc:1319 #23 0x000055d2abaed3d2 in sp_head::execute_procedure (this=0x7f400e23d088, thd=0x7f4013271070, args=0x7f4013275710) at /home/elenst/10.1/sql/sp_head.cc:2106 #24 0x000055d2ab763b0d in do_execute_sp (thd=0x7f4013271070, sp=0x7f400e23d088) at /home/elenst/10.1/sql/sql_parse.cc:2403 #25 0x000055d2ab76ce0f in mysql_execute_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:5254 #26 0x000055d2ab772eef in mysql_parse (thd=0x7f4013271070, rawbuf=0x7f400b7f7088 "CALL p_update_ccs_system(122)", length=29, parser_state=0x7f403951d630) at /home/elenst/10.1/sql/sql_parse.cc:7318 #27 0x000055d2ab7615f3 in dispatch_command (command=COM_QUERY, thd=0x7f4013271070, packet=0x7f4013297071 "CALL p_update_ccs_system(122)", packet_length=29) at /home/elenst/10.1/sql/sql_parse.cc:1487 #28 0x000055d2ab760323 in do_command (thd=0x7f4013271070) at /home/elenst/10.1/sql/sql_parse.cc:1108 #29 0x000055d2ab896719 in do_handle_one_connection (thd_arg=0x7f4013271070) at /home/elenst/10.1/sql/sql_connect.cc:1350 #30 0x000055d2ab896468 in handle_one_connection (arg=0x7f4013271070) at /home/elenst/10.1/sql/sql_connect.cc:1262 #31 0x00007f4037e146fa in start_thread (arg=0x7f403951eb00) at pthread_create.c:333 #32 0x00007f40374bfb5d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109

Elena Stepanova added a comment - 2016-10-08 09:52

mnewcomb2016, thanks for the report and test case.

sanja, below is a smaller test for debugging; but after fixing, please make sure that your fix also works for the initial test case!
(it's big and takes long time).

drop table if exists t, tmp_t;

create table t (id int auto_increment primary key);

insert into t values (9494),(9495),(9496),(9497),(9498),(9499),(9500),(9501),(9502),(9503);

create or replace VIEW v AS

select id from t

union

select id from t

drop procedure if exists p;

create procedure p()

insert into tmp_t select t.id from (

    select id from v

    union

    select id from v

) sq

inner join t on (sq.id = t.id);

--error ER_NO_SUCH_TABLE

CALL p();

create table tmp_t (id int null);

CALL p();

Elena Stepanova added a comment - 2016-10-08 09:52 mnewcomb2016 , thanks for the report and test case. sanja , below is a smaller test for debugging; but after fixing, please make sure that your fix also works for the initial test case! (it's big and takes long time). drop table if exists t, tmp_t; create table t (id int auto_increment primary key ); insert into t values (9494),(9495),(9496),(9497),(9498),(9499),(9500),(9501),(9502),(9503); create or replace VIEW v AS select id from t union select id from t ; drop procedure if exists p; create procedure p() insert into tmp_t select t.id from ( select id from v union select id from v ) sq inner join t on (sq.id = t.id); --error ER_NO_SUCH_TABLE CALL p(); create table tmp_t (id int null ); CALL p();

Elena Stepanova made changes - 2016-10-08 09:54

Fix Version/s		10.1 [ 16100 ]
Fix Version/s		10.2 [ 14601 ]
Affects Version/s		10.1 [ 16100 ]
Affects Version/s		10.2 [ 14601 ]
Assignee		Oleksandr Byelkin [ sanja ]

Rasmus Johansson (Inactive) made changes - 2016-10-26 19:55

Sprint

10.1.19 [ 109 ]

Rasmus Johansson (Inactive) made changes - 2016-10-26 19:55

Rank

Ranked higher

Rasmus Johansson (Inactive) made changes - 2017-01-11 08:14

Sprint

10.1.19 [ 109 ]

10.1.19, 10.1.21 [ 109, 130 ]

Rasmus Johansson (Inactive) made changes - 2017-01-11 08:14

Rank

Ranked lower

Oleksandr Byelkin made changes - 2017-01-11 10:31

Status

Confirmed [ 10101 ]

In Progress [ 3 ]

Oleksandr Byelkin added a comment - 2017-01-11 13:18

The problem is that we have 2 SELECT # 2

Oleksandr Byelkin added a comment - 2017-01-11 13:18 The problem is that we have 2 SELECT # 2

Oleksandr Byelkin added a comment - 2017-01-11 15:25

There is only 1 select #2, but explain information was not cleaned after error, which causes problem:
we check if there is explein info for select # 2 and there is (from forest run with error), so we do not create new, and so JOIN::explain is left NULL.

Oleksandr Byelkin added a comment - 2017-01-11 15:25 There is only 1 select #2, but explain information was not cleaned after error, which causes problem: we check if there is explein info for select # 2 and there is (from forest run with error), so we do not create new, and so JOIN::explain is left NULL.

Oleksandr Byelkin added a comment - 2017-01-13 20:23

OK, despite the same SQL inside it is 2 different SELECT_LEX & JOIN with number #2 and number #3 and both part of the view UNION.
so probably the view was built in the statement before error, then made it second time. then optimized one select #2 and explain saved, then second select #2 and explain is not saved (because it is "present") then it fail.

Oleksandr Byelkin added a comment - 2017-01-13 20:23 OK, despite the same SQL inside it is 2 different SELECT_LEX & JOIN with number #2 and number #3 and both part of the view UNION. so probably the view was built in the statement before error, then made it second time. then optimized one select #2 and explain saved, then second select #2 and explain is not saved (because it is "present") then it fail.

Oleksandr Byelkin added a comment - 2017-01-15 20:06

mysql_make_view works only in CALL without error.

Oleksandr Byelkin added a comment - 2017-01-15 20:06 mysql_make_view works only in CALL without error.

Oleksandr Byelkin added a comment - 2017-01-15 20:18

first time mysql_new_select called during compiling call with error, second during mysql_make_view in normal CALL.

Oleksandr Byelkin added a comment - 2017-01-15 20:18 first time mysql_new_select called during compiling call with error, second during mysql_make_view in normal CALL.

Oleksandr Byelkin added a comment - 2017-01-15 20:20 - edited

If there is no error all calls made in the same first CALL, and everything is OK.

Oleksandr Byelkin added a comment - 2017-01-15 20:20 - edited If there is no error all calls made in the same first CALL, and everything is OK.

Oleksandr Byelkin added a comment - 2017-01-15 20:26

Normal execution has only one select #2 and one #3 used everywhere (as it should).

Oleksandr Byelkin added a comment - 2017-01-15 20:26 Normal execution has only one select #2 and one #3 used everywhere (as it should).

Oleksandr Byelkin added a comment - 2017-01-15 20:27

incorrect switching Query_arenas ?

Oleksandr Byelkin added a comment - 2017-01-15 20:27 incorrect switching Query_arenas ?

Oleksandr Byelkin added a comment - 2017-01-16 09:31

Correct execution has the same SELECT_LEX (why view selects 2 times?), but counting them from beginning because process divided between 2 calls cause the problem we observe.

Oleksandr Byelkin added a comment - 2017-01-16 09:31 Correct execution has the same SELECT_LEX (why view selects 2 times?), but counting them from beginning because process divided between 2 calls cause the problem we observe.

Oleksandr Byelkin added a comment - 2017-01-16 13:33

Workaround can be store thd->select_number and then restore it before execution, but what is statement like this will not be the first in the procedure.

Oleksandr Byelkin added a comment - 2017-01-16 13:33 Workaround can be store thd->select_number and then restore it before execution, but what is statement like this will not be the first in the procedure.

Oleksandr Byelkin added a comment - 2017-01-17 09:54

There is other way (without error) to repeat the problem. It need just other statement to reset thd->select_number between parsing and execution.

create table t (id int auto_increment primary key);

insert into t values (9494),(9495),(9496),(9497),(9498),(9499),(9500),(9501),(9502),(9503);

create VIEW v AS

select id from t

union

select id from t

delimiter |;

create procedure p()

begin

  select 1;

  insert into tmp_t select t.id from (

      select id from v

      union

      select id from v

  ) sq

  inner join t on (sq.id = t.id);

end |

delimiter ;|

create table tmp_t (id int null);

CALL p();

drop procedure p;

drop view v;

drop table t, tmp_t;

Oleksandr Byelkin added a comment - 2017-01-17 09:54 There is other way (without error) to repeat the problem. It need just other statement to reset thd->select_number between parsing and execution. create table t (id int auto_increment primary key); insert into t values (9494),(9495),(9496),(9497),(9498),(9499),(9500),(9501),(9502),(9503); create VIEW v AS select id from t union select id from t ; delimiter |; create procedure p() begin select 1; insert into tmp_t select t.id from ( select id from v union select id from v ) sq inner join t on (sq.id = t.id); end | delimiter ;| create table tmp_t (id int null); CALL p(); drop procedure p; drop view v; drop table t, tmp_t;

Oleksandr Byelkin added a comment - 2017-01-17 09:56

As a solution I see storing the counter (thd->select_number) in sp_head and restore it before each instruction.

Oleksandr Byelkin added a comment - 2017-01-17 09:56 As a solution I see storing the counter (thd->select_number) in sp_head and restore it before each instruction.

Oleksandr Byelkin added a comment - 2017-01-17 10:38

Above was wrong (rests of experimenting with instructions).

Stored procedure do not reset the counter between instructions, so it number all selects in the procedure.

Oleksandr Byelkin added a comment - 2017-01-17 10:38 Above was wrong (rests of experimenting with instructions). Stored procedure do not reset the counter between instructions, so it number all selects in the procedure.

Oleksandr Byelkin added a comment - 2017-01-17 10:53

Problem present in 5.5/10.0 but do not lead to crash, because it has different EXPLAIN system.

Oleksandr Byelkin added a comment - 2017-01-17 10:53 Problem present in 5.5/10.0 but do not lead to crash, because it has different EXPLAIN system.

Oleksandr Byelkin added a comment - 2017-01-17 12:10

revision-id: f360516046af16336e874b1ab9fb22efb1881723 (mariadb-10.1.20-33-gf360516046a)
parent(s): 5044dae239d094582879792de7a762d3428223ce
committer: Oleksandr Byelkin
timestamp: 2017-01-17 13:09:04 +0100
message:

~~MDEV-10972~~: Insert from select / view / union – repeatable crash in 10.1, 10.2 Linux/Mac/Windows

save thd->select_number between parsing and executions (in case it was not complete executed due to errors (for example epsent table))

—

Oleksandr Byelkin added a comment - 2017-01-17 12:10 revision-id: f360516046af16336e874b1ab9fb22efb1881723 (mariadb-10.1.20-33-gf360516046a) parent(s): 5044dae239d094582879792de7a762d3428223ce committer: Oleksandr Byelkin timestamp: 2017-01-17 13:09:04 +0100 message: MDEV-10972 : Insert from select / view / union – repeatable crash in 10.1, 10.2 Linux/Mac/Windows save thd->select_number between parsing and executions (in case it was not complete executed due to errors (for example epsent table)) —

Oleksandr Byelkin made changes - 2017-01-17 12:10

Assignee	Oleksandr Byelkin [ sanja ]	Sergei Petrunia [ psergey ]
Status	In Progress [ 3 ]	In Review [ 10002 ]

Oleksandr Byelkin added a comment - 2017-01-17 17:14

The very first SELECT_LEX which belong to LEX should not be a problem.

Oleksandr Byelkin added a comment - 2017-01-17 17:14 The very first SELECT_LEX which belong to LEX should not be a problem.

Rasmus Johansson (Inactive) made changes - 2017-01-18 10:04

Sprint

10.1.19, 10.1.21 [ 109, 130 ]

10.1.19, 10.2.4-1 [ 109, 132 ]

Rasmus Johansson (Inactive) made changes - 2017-01-18 10:04

Rank

Ranked lower

Rasmus Johansson (Inactive) made changes - 2017-01-26 10:37

Sprint

10.1.19, 10.2.4-1 [ 109, 132 ]

10.1.19, 10.2.4-1, 10.2.4-2 [ 109, 132, 134 ]

Michael Newcomb made changes - 2017-06-26 12:36

Link

This issue relates to ~~MDEV-13174~~ [ ~~MDEV-13174~~ ]

Oleksandr Byelkin added a comment - 2017-09-04 13:31

revision-id: c62864b57568e81d77a1ffa2d7ad96d5daccfe97 (mariadb-10.1.26-26-gc62864b5756)
parent(s): 4d158d71a667dfbf8f679e1e6abd5f46813b5e2f
author: Oleksandr Byelkin
committer: Oleksandr Byelkin
timestamp: 2017-09-04 15:29:58 +0200
message:

Post review change (prevents contant increasing, which harmless but not right)

—

Oleksandr Byelkin added a comment - 2017-09-04 13:31 revision-id: c62864b57568e81d77a1ffa2d7ad96d5daccfe97 (mariadb-10.1.26-26-gc62864b5756) parent(s): 4d158d71a667dfbf8f679e1e6abd5f46813b5e2f author: Oleksandr Byelkin committer: Oleksandr Byelkin timestamp: 2017-09-04 15:29:58 +0200 message: Post review change (prevents contant increasing, which harmless but not right) —

Sergei Petrunia added a comment - 2017-09-04 14:25

Review input provided in chat window. Ok to push after addressed.

Sergei Petrunia added a comment - 2017-09-04 14:25 Review input provided in chat window. Ok to push after addressed.

Sergei Petrunia made changes - 2017-09-04 14:25

Assignee	Sergei Petrunia [ psergey ]	Oleksandr Byelkin [ sanja ]
Status	In Review [ 10002 ]	Stalled [ 10000 ]

Oleksandr Byelkin made changes - 2017-09-04 14:53

Fix Version/s		10.1.27 [ 22609 ]
Fix Version/s		10.2.9 [ 22611 ]
Fix Version/s		10.3.2 [ 22533 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.1 [ 16100 ]
Resolution		Fixed [ 1 ]
Status	Stalled [ 10000 ]	Closed [ 6 ]

Oleksandr Byelkin made changes - 2017-09-04 14:55

Link

This issue is duplicated by ~~MDEV-13174~~ [ ~~MDEV-13174~~ ]

Oleksandr Byelkin made changes - 2017-09-04 14:55

Link

This issue is duplicated by ~~MDEV-13365~~ [ ~~MDEV-13365~~ ]

Alice Sherepa made changes - 2018-09-01 21:27

Link

This issue relates to ~~MDEV-16618~~ [ ~~MDEV-16618~~ ]

Alice Sherepa made changes - 2018-09-01 21:30

Link

This issue relates to ~~MDEV-16618~~ [ ~~MDEV-16618~~ ]

Sergei Golubchik made changes - 2021-12-06 21:43

Workflow

MariaDB v3 [ 77692 ]

MariaDB v4 [ 151020 ]

People

Assignee:: Oleksandr Byelkin

Reporter:: Michael Newcomb

Votes:: 0 Vote for this issue

Watchers:: 4 Start watching this issue

Dates

Created:: 2016-10-06 20:47

Updated:: 2018-09-01 21:30

Resolved:: 2017-09-04 14:53

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Issue Links

Activity

People

Dates

Git Integration