Calling a stored function that uses a cursor inside its body
could produce the error ER_NO_SUCH_TABLE on the second execution
in case the cursor uses multi-table query and one of the tables
is a temporary table just created before querying the cursor and
dropped just after the query has been executed.
The reason for issue is that re-parsing of failed a SP instruction
caused be create/drop of the temporary table used LEX object
left from previous parsing of a SP instruction's query instead
re-initialize the lex object before parsing.
To fix the issue, add initialization of lex for cursor's
statement before re-parsing the query of a failed SP instruction.
This bug report was caused by implementation of the task MDEV-5816
(Stored programs: validation of stored program statements).
Changing metadata of a table that has a trigger on AFTER UPDATE or AFTER DELETE
resulted in unexpected output of the error ER_TRG_NO_SUCH_ROW_IN_TR.
It was caused by the fact that characteristics of the trigger dependent on
changed table's metadata wasn't set in a new lex object created on re-parsing
of a failing trigger statement.
To fix the bug the data member lex->trg_chistics.action_time and
lex->trg_chistics.event must be set into real values of the trigger
whose statement being re-parsed.
This is the follow-up patch for the task MDEV-5816 that fixes assert failure
that happened after recompilation of a stored routine containing a cursor
on its second execution.
The reason of assertion hit is that a state of the SP instruction sp_instr_cpush
wasn't reset after its SQL statement re-compiled.
To fix the issue the virtual method sp_lex_instr::on_after_expr_parsing
is overridden in the derived class sp_instr_cpush. Implementation of this method
does resetting of the data member sp_instr_cpush::m_metadata_changed
Additionally, implementation of the method
sp_instr_set_trigger_field::on_after_expr_parsing
has been slightly modified to set the data member
sp_instr_set_trigger_field::value
just before successful return. This data member is used to check whether this
SP instruction is still valid or should be re-compiled.
Resetting this data member before an instance of the class Item_trigger_field
be successfully allocated theoretically could lead to clearing of instruction's
state despite the fact that memory allocation was failed.
The follow-up patch to check in mtr tests that recompilation of
a SP's instruction doesn't lead to eviction of SP from sp_cache.
This patch adds the debug keyword 'check_sp_cache_not_invalidated'
checked in sp_cache_flush_obsolete. In case this debug keyword
is set the macros DBUG_SUICIDE() called to cause test failure.
The function sp_cache_flush_obsolete() is called on opening
a stored routine. So setting this keyword before second execution
of some stored routine that supposed to cause recompilation of
SP's statement will guarantee that this stored routine not evicted
from sp_cache.
Suggested approach has one limitation - the statement
CREATE/ALTER/DROP VIEW
forces invalidation of the whole sp_cache (by invoking the function
sp_cache_invalidate()).
So, for those tests (actually, there are very small number of such tests)
that create/alter/drop a view before the second execution of some stored
routine, the debug keyword 'check_sp_cache_not_invalidated' isn't set.
The proposal to add some way a check that a stored routine is not force out
from sp_cache on re-parsing a failing statement of a stored routine was
done during reiew, that is the reason the proposed change has been formatted
as a separate patch.
