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#21824519: ASSERTION IN DROP TRIGGER WHEN TABLE HAS VIRTUAL GENERATED COLUMN
In some cases a DROP TRIGGER statement could hit a DBUG_ASSERT in
debug builds if the trigger was defined on a table that contained a
generated column. The same DBUG_ASSERT could under some circumstances
be hit when calling a stored function that referenced a table that
contained a generated column.
The DBUG_ASSERT was hit during re-resolving (aka "refixing") of the
generated column expression. The first time a statement opens a table
that contains a generated column, all the generated columns in that
table will be re-resolved to ensure that they are in a pristine state.
The DBUG_ASSERT (in TABLE_LIST::map()) fails because the TABLE_LIST
object associated with the Item_field that is being re-resolved, is in
an inconsistent state where m_map is not in sync with m_tableno.
The TABLE_LIST objects in question are allocated in
sp_add_to_query_tables() in the DROP TRIGGER case and in
sp_head::add_used_tables_to_table_list() in the stored function case.
Common for these two functions is that they initialize the TABLE_LIST
objects by manually setting the various members, instead of calling
TABLE_LIST::init_one_table(), which is the common way of initializing
such objects. This manual initialization forgets to set the m_map and
m_tableno members to values that are consistent with each other.
The fix makes the functions use init_one_table() to initialize the
TABLE_LIST objects. init_one_table() also needed a little reorganizing
to allow more flexible initialization of the associated lock request.
(cherry picked from commit 1aabcfde317a5b96bf9d33226795aa096db2aab8)
0 commit comments