Bug #19306524 FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED
FROM A FUNCTION Scenario: In a stored procedure, CREATE TABLE statement is not allowed. But an exception is provided for CREATE TEMPORARY TABLE. We can create a temporary table in a stored procedure. Let there be two stored functions f1 and f2 and two stored procedures p1 and p2. Their properties are as follows: . stored function f1() calls stored procedure p1(). . stored function f2() calls stored procedure p2(). . stored procedure p1() creates temporary table t1. . stored procedure p2() does DML on t1. Consider the following situation: 1. Autocommit mode is on. 2. select f1() 3. select f2() Step 2: In this step, t1 would be created via p1(). A table level transaction lock would have been taken. The ::external_lock() would not have been called on this table. At the end of step 2, because of autocommit mode on, this table level lock will be released. Step 3: When we execute DML on table t1 via p2() we have two problems: Problem 1: The function ha_innobase::external_lock() would have been called but since it is a select query no table level locks would have been taken. Hence the following assert will fail: ut_ad(lock_table_has(thr_get_trx(thr), index->table, LOCK_IX)); Solution: The solution would be to identify this situation and take a table level lock and use the proper lock type prebuilt->select_lock_type = LOCK_X for DML operations. Problem 2: Another problem is that in step 3, ha_innobase::open() is never called on the table t1. Solution: The solution would be to identify this situation and call re-init the handler of table t1. rb#6429 approved by Krunal.
Showing
Please register or sign in to comment