MDEV-14959: Fixed memory leak happened on re-parsing a view that substitutes a table
In case a table accessed by a PS/SP is dropped after the first execution of PS/SP and a view created with the same name as a table just dropped then the second execution of PS/SP leads to allocation of a memory on SP/PS memory root already marked as read only on first execution. For example, the following test case: CREATE TABLE t1 (a INT); PREPARE stmt FROM "INSERT INTO t1 VALUES (1)"; EXECUTE stmt; DROP TABLE t1; CREATE VIEW t1 S SELECT 1; --error ER_NON_INSERTABLE_TABLE EXECUTE stmt; # (*) DROP VIEW t1; will hit assert on running the statement 'EXECUTE stmt' marked with (*) when allocation of a memory be performed on parsing the view. Memory allocation is requested inside the function mysql_make_view when a view definition being parsed. In order to avoid an assertion failure, call of the function mysql_make_view() must be moved after invocation of the function check_and_update_table_version(). It will result in re-preparing the whole PS statement or current SP instruction that will free currently allocated items and reset read_only flag for the memory root.
Showing
Please register or sign in to comment