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
When an expression is used in the index clause of a CREATE TABLE
statement in a prepared statement the first execution of the prepared
statement will succeed, but a subsequent execution will encounter
an error. Similar errors also occur with expressions used in CREATE
INDEX and ALTER TABLE ADD INDEX statements.
A similar error is encountered when using expressions in the PARTITION
clauses of a CREATE TABLE statement in a prepared statement.
Likewise, these forms of CREATE TABLE, CREATE INDEX and ALTER TABLE
ADD INDEX statements cause errors when used in stored procedures.
The root cause of the issue is a mismatch of lifetimes of parse tree
objects used for the offending statements. When an offending statement
is initially parsed during the creation of a prepared statement the
parse tree objects are allocated in a MEM_ROOT whose lifetime is
associated with the lifetime of the prepared statement. When the
prepared statement is executed, the parse tree objects corresponding to
the index or partition expressions are allocated in a MEM_ROOT whose
lifetime is limited to the execution of the prepared statement.
Unfortunately, pointers to these expression parse tree objects are held
in the memory belonging to the first MEM_ROOT, so subsequent executions
of the prepared statement are attempted with parse tree structures that
hold pointers to invalid memory (i.e. pointers into the second MEM_ROOT
that was freed/invalidated at the end of the first execution).
A similar pattern of parse tree memory usage is present in stored
procedures that use the offending CREATE TABLE, CREATE INDEX and ALTER
TABLE CREATE INDEX statements.
To fix this issue, prepared statements and stored procedures using the
offending statements are now reprepared/reparsed prior to second and
subsequent executions so that memory access via pointers to
invalidated/freed memory is avoided. This is a short term fix: a longer
term fix will involve refactoring the initial preparation of the parse
trees for the offending statements so that they can be used in multiple
executions without having to reparse each time.
Change-Id: Ic1601a8b9bddc754f17d3df8e86bc1be3c01cd30
0 commit comments