#15 0x00007fb8fc2fbbbf in handle_select (thd=0x7fb8f2ab2070, lex=0x7fb8f0c7bb68, result=0x7fb8f0c8b1a0, setup_tables_done_option=0) at 10.1/sql/sql_select.cc:371
#16 0x00007fb8fc2bc071 in execute_sqlcom_select (thd=0x7fb8f2ab2070, all_tables=0x7fb8f0c82188) at 10.1/sql/sql_parse.cc:5805
#17 0x00007fb8fc2b24aa in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:2937
#18 0x00007fb8fc61368c in sp_instr_stmt::exec_core (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3135
#19 0x00007fb8fc612dcb in sp_lex_keeper::reset_lex_and_exec_core (this=0x7fb8f0c827a8, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124, open_tables=false, instr=0x7fb8f0c82768) at 10.1/sql/sp_head.cc:2901
#20 0x00007fb8fc613394 in sp_instr_stmt::execute (this=0x7fb8f0c82768, thd=0x7fb8f2ab2070, nextp=0x7fb8fbd19124) at 10.1/sql/sp_head.cc:3051
#21 0x00007fb8fc60efca in sp_head::execute (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, merge_da_on_success=true) at 10.1/sql/sp_head.cc:1316
#22 0x00007fb8fc610e62 in sp_head::execute_procedure (this=0x7fb8f0c7b088, thd=0x7fb8f2ab2070, args=0x7fb8f2ab66b0) at 10.1/sql/sp_head.cc:2103
#23 0x00007fb8fc2b0c9d in do_execute_sp (thd=0x7fb8f2ab2070, sp=0x7fb8f0c7b088) at 10.1/sql/sql_parse.cc:2383
#24 0x00007fb8fc2b9d0e in mysql_execute_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:5180
#25 0x00007fb8fc2bf5de in mysql_parse (thd=0x7fb8f2ab2070, rawbuf=0x7fb8f0c22088 "CALL proc()", length=11, parser_state=0x7fb8fbd1a180) at 10.1/sql/sql_parse.cc:7181
#26 0x00007fb8fc2ae772 in dispatch_command (command=COM_QUERY, thd=0x7fb8f2ab2070, packet=0x7fb8f2ab8071 "CALL proc()", packet_length=11) at 10.1/sql/sql_parse.cc:1470
#27 0x00007fb8fc2ad49d in do_command (thd=0x7fb8f2ab2070) at 10.1/sql/sql_parse.cc:1093
#28 0x00007fb8fc3ee1f5 in do_handle_one_connection (thd_arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1350
#29 0x00007fb8fc3edf59 in handle_one_connection (arg=0x7fb8f2ab2070) at 10.1/sql/sql_connect.cc:1262
#30 0x00007fb8fcaa4f7c in pfs_spawn_thread (arg=0x7fb8f9023ff0) at 10.1/storage/perfschema/pfs.cc:1860
#31 0x00007fb8fa6bee9a in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0
#32 0x00007fb8f9debcbd in clone () from /lib/x86_64-linux-gnu/libc.so.6
Sequential execution works because it makes full re-prepare of the procedure including views re-parsing, when in parallel execution one view is used as it was stored and other is parsed (and counter set wrongly).
Oleksandr Byelkin
added a comment - Sequential execution works because it makes full re-prepare of the procedure including views re-parsing, when in parallel execution one view is used as it was stored and other is parsed (and counter set wrongly).
MDEV-8087: Server crashed in Time_and_counter_tracker::incr_loops
Problem:
Procedure which uses stack of views first executed without most deep view. It fails but one view cached.
Then simultaniusely create the view we lack and execute the procedure.
In the beginning of procedure execution views are not yet changes so procedure used as it was cached.
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.
The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.
—
Oleksandr Byelkin
added a comment - revision-id: a3c33026bc1f3a8efe3a165661786e7bc08bea34 (mariadb-10.1.6-108-ga3c3302)
parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8
committer: Oleksandr Byelkin
timestamp: 2015-09-22 21:59:18 +0200
message:
MDEV-8087 : Server crashed in Time_and_counter_tracker::incr_loops
Problem:
Procedure which uses stack of views first executed without most deep view. It fails but one view cached.
Then simultaniusely create the view we lack and execute the procedure.
In the beginning of procedure execution views are not yet changes so procedure used as it was cached.
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.
The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.
—
Also the question is should we allow the situation when view changes and the procedure which uses it is not invalidated.
Situation is possible if we had problem with the view before and only when creating/altering view made in the same time with the procedure call but still can possibly bring some other problems.
Oleksandr Byelkin
added a comment - Also the question is should we allow the situation when view changes and the procedure which uses it is not invalidated.
Situation is possible if we had problem with the view before and only when creating/altering view made in the same time with the procedure call but still can possibly bring some other problems.
MDEV-8087: Server crashed in Time_and_counter_tracker::incr_loops
Problem:
Procedure which uses stack of views first executed without most deep view.
It fails but one view cached (as well as whole procedure).
Then simultaniusely create the second view we lack and execute the procedure.
In the beginning of procedure execution the view is not yet created so
procedure used as it was cached (cache was not invalidated).
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.
The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.
—
Oleksandr Byelkin
added a comment - fix with test suite:
revision-id: ccb6b0dd1fb603673dbcfe7d1763bd3fe5d3bcaf (mariadb-10.1.6-108-gccb6b0d)
parent(s): 20291639994beaa070b7228eafa7be31eb1d7ff8
committer: Oleksandr Byelkin
timestamp: 2015-10-06 19:54:56 +0200
message:
MDEV-8087 : Server crashed in Time_and_counter_tracker::incr_loops
Problem:
Procedure which uses stack of views first executed without most deep view.
It fails but one view cached (as well as whole procedure).
Then simultaniusely create the second view we lack and execute the procedure.
In the beginning of procedure execution the view is not yet created so
procedure used as it was cached (cache was not invalidated).
But by the time we are trying to use most deep view it is already created.
The problem with the view is that thd->select_number (first view was not parsed) so second view will get the same number.
The fix is in keeping the thd->select_number correct even if we use cached views.
In the proposed solution (to keep it simple) counter can be bigger then should but it should not create problem because numbers are still unique and situation is very rare.
—
Bug
Major
Sequential execution works because it makes full re-prepare of the procedure including views re-parsing, when in parallel execution one view is used as it was stored and other is parsed (and counter set wrongly).