You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Bug#36980896: Defining local variables within a TRIGGER/PROCEDURE
causes service to shut down
There are two problems here: With a production binary, we see failures
in check_column_privileges() or failing to obtain a virtual function
for an Item_func_eq object.
With a debug binary, execution fails earlier in an assert:
Query_expression::set_prepared(), Assertion `!is_prepared()' failed.
Due to the assert failing in debug mode, it is difficult to get to the
actual source of the problem, but we can narrow the debug issue down
to establishing a proper execution context for an independent item
to be evaluated in function sp_prepare_func_item(). The assumption
for this function is that the current LEX and query expression found
through thd->lex can be set to "prepared" and "executing" state.
However, sp_prepare_func_item() can be used for two kinds of items.
Some of these are standalone and have an associated LEX object and
a query expression object. Examples of these are the procedure
instructions sp_instr_set and sp_instr_jump_if_not. Others are
expressions that are created below a LEX that is already in an
executing state. Examples are items used to assign values to procedure
arguments after procedure execution, and assignment to local variables
after query execution. The latter is the problem in this case.
The solution to the first problem is to distinguish the two cases and
pass a bool argument for the standalone items and false for the
remaining ones. In sp_prepare_func_item(), we then ensure that
preparation and execution state is set properly for the standalone
items, whereas we ensure by inspecting the current LEX object that we
are already in an executing context for the dependent items.
The second problem is related to the first one. It started appearing
after the fix for bug#35856247 was pushed, which changes the way
base_ref_items are saved in Query_block::save_properties().
But the solution also fixes this problem, since we no longer save
properties for dependent items, which will interfere with the already
saved properties for the current query block.
We also had to set proper execution state in
Sql_cmd_get_diagnostics::execute() and Sql_cmd_load_table::execute()
because otherwise these functions would fail the newly added asserts.
Change-Id: Ib5d31c07994340006818e180eed74e1d6aa23280
0 commit comments