aaedae5...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
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 routing 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.
90a62c5...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Added mtr tests for MDEV-5816
5d20935...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Fix of existing mtr tests.
6de0348...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
This patch fixes the issue with missing warnings generated on re-parsing
a failing SP instruction's statement. That is, any warning generated
on re-parsing a statement was discarded after SP instruction's a statement
has been successfully re-parsed.
The reason for discarding warnings after re-parsing is that the method
THD::set_query_id()
called every time when a failing SP instruction re-parsed.
In result,
Warning_info::m_warn_id != thd->query_id
and when the method
Diagnostics_area::opt_clear_warning_info(thd->query_id)
is invoked from sp_head::execute all warnings accumulated during
execution of the current SP instruction is cleared.
So, to fix the issue invokes the method THD::set_query_id()
once per SP instruction, on its first execution. Re-parsing of failing
SP instruction and following run of it don't invoke the method
THD::set_query_id().
7b59f8a...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
This patch is the second part of implementation for cursor's statement
re-parsing. The patch does the following changes:
- on re-parsing a failed SP instruction that does need to get access
to LEX a new lex is instantiated for every SP instruction except
cursor relating SP instructions.
- items created on re-parsing a cursor relating statement are moved
to the free_list of sp_lex_cursor.
4fd4227...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Added re-parsing of a failing cursor body. Re-parsing of a failing
SP statement is implemented by the method validate_lex_and_exec_core(),
therefore invocation of the method reset_lex_and_exec_core() inside
sp_lex_keeper::cursor_reset_lex_and_exec_core
was replaced by the method validate_lex_and_exec_core().
Re-parsing of a failed SP statement is relied upon interface provided
by the class sp_lex_instr (the methods used for this goal are
is_invalid(), parse_expr(), invalidate(), get_query(), get_expr_query()).
To provide access to these methods on opening a cursor, the signature of
the method
sp_lex_keeper::cursor_reset_lex_and_exec_core
was changed to accept a pointer to the class sp_lex_instr instead of
the class sp_instr, and the new method get_push_instr() was added
into the class sp_cursor. This method is to get access to an instance
of the class sp_instr_cpush on opening a cursor (on handling the statement
OPEN cursors_name).
Default implementation of this method just returns NULL pointer of
the type sp_instr_cpush. This method is overridden in the class
sp_instr_cpush with trivial implementation
{ return this; }
On handling the statement DECLARE CURSOR FOR the new instruction of
the type sp_instr_cpush is added into sp_head. The class sp_instr_cpush
holds a text of SELECT query referencing by a cursor declaration.
When a cursor is being opened (on handling the statement 'OPEN cur_name')
a pointer to sp_instr_cpush is returned by the method
sp_cursor::get_push_instr()
and this pointer is passed to the method
sp_lex_keeper::cursor_reset_lex_and_exec_core
in order to open a cursor and provide access to an interface required
for SP statement re-parsing in case metadata changes took place.
Since real access to a lex object is required on handling instruction
sp_instr_cpush (an instance of this class is created during parsing of
cursor declaration statement), calling of the method sp_cursor::open
is moved from the method
sp_instr_copen::exec_core
into the method
sp_instr_cpush::exec_core.
Additionally, updated the methods get_query/get_expr_query in the classes
sp_instr_cpush, sp_instr_cursor_copy_struct in order to return correct text of
cursor's body taking into account that lexer treated the clause CURSOR FOR/
CURSOR IS as two different tokens following one after another. So, to return
a correct text of SELECT statement specified in CURSOR declaration statement,
the token FOR/IS should be skipped and text following it should be returned as
a text of cursors's query.
e859105...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Introduced the new data member new_query_arena_is_set of the class sp_head.
This data member is used as a protection against double invocation of
the method restore_thd_mem_root that is called for restoration of the
current query arena. Previously, the data member sp_head::m_thd
is used for this goal but after support for re-compilation of a failed
stored routine statement has been added the data member sp_head::m_thd
can't be used for this goal. The reason is that on a statement re-compilation
after the method restore_thd_mem_root() is called the method
sp_head::add_instr() invoked to add a new instruction for just re-compiled
statement. The method sp_head::add_instr() de-references m_thd to access
the free_list data member. If m_thd was used as a guard against double
invocation it would result in a crash on dereferencing null pointer.
34c6332...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Fixed memory leakage taken place on execution of the statement
SHOW CREATE PACKAGE `pkg_name`
The memory leak was caused by implementation of sp_compile()
where a memory root for a stored routine was allocated but
a pointer to the new memory root wasn't passed to sp_package::create
for subsequent forwarding to the constructor of sp_package.
Instead, another one mempory root was allocated and the pointer to
the original memory root was missed.
d9c74a1...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Re-designed a way by that Item_trigger_field objects are arranged in memory.
Item_trigger_field objects created on parsing a trigger's statement
is now stored in a per statement list. All lists of Item_trigger_field
objects created on parsing the whole trigger's body are organized
in the structure "list of lists". So, to iterate every
Item_trigger_field object created on parsing a trigger body,
it required to use binary cycle.
To organize the list of lists structure the new data member
Item_trigger_field::next_trig_field_list
is introduced that links lists in this hierarchy structure.
This re-design is performed in order to avoid refences to already
deleted items on re-compilation of failed trigger's statememt.
Referencing to already deleted item could take place on re-parsing
a trigger's statement since every Item created for a statement
being re-parsed is deleted before the statement is re-parsed,
but deleted items are still referenced from sp_head. So, to avoid
access to dangling references a per statement list of Item_trigger_field
objects is cleared right after the current SP statement is cleaned up
and before re-parsing is started.
09710e8...
by
Dmitry Shulga <email address hidden>
MDEV-5816: Stored programs: validation of stored program statements
Added re-parsing of failed statements inside a stored routine.
General idea of the patch is to install an instance of the class
Reprepare_observer before executing a next SP instruction and
re-parse a statement of this SP instruction in case of
its execution failure.
To implement the described approach the class sp_lex_keeper
has been extended with the method validate_lex_and_exec_core()
that is just a wrapper around the method reset_lex_and_exec_core()
with additional setting/resetting an instance of the class
Reprepare_observer on each iteration of SP instruction
execution.
If reset_lex_and_exec_core() returns error and an instance
of the class Reprepare_observer is installed before running
a SP instruction then a number of attempts to re-run the SP
instruction is checked against a max. limit and in case it doesn't
reach the limit a statement for the failed SP instruction is re-parsed.
Re-parsing of a statement for the failed SP instruction is implemented
by the new method sp_le_inst::parse_expr() that prepends
a SP instruction's statement with the clause 'SELECT' and parse it.
Own SP instruction MEM_ROOT and a separate free_list is used for
parsing of a SP statement. On successful re-parsing of SP instruction's
statement the virtual methods adjust_sql_command() and
on_after_expr_parsing() of the class sp_lex_instr is called
to update the SP instruction state with a new data created
on parsing the statement.
Few words about reason for prepending a SP instruction's statement
with the clause 'SELECT' - this is required step to produce a valid
SQL statement, since for some SP instructions the instructions statement
is not a valid SQL statement. Wrapping such text into 'SELECT ( )'
produces a correct operator from SQL syntax point of view.
