• Annamalai Gurusami's avatar
    Bug #19306524 FAILING ASSERTION WITH TEMP TABLE FOR A PROCEDURE CALLED · db78f29b
    Annamalai Gurusami authored
    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.
    db78f29b
sp_temp_table.test 2.51 KB