• unknown's avatar
    A fix and a test case for Bug#15217 "Using a SP cursor on a table created · 67fd3c4a
    unknown authored
     with PREPARE fails with weird error".
    More generally, re-executing a stored procedure with a complex SP cursor query
    could lead to a crash.
    
    The cause of the problem was that SP cursor queries were not optimized 
    properly at first execution: their parse tree belongs to sp_instr_cpush,
    not sp_instr_copen, and thus the tree was tagged "EXECUTED" when the
    cursor was declared, not when it was opened. This led to loss of optimization
    transformations performed at first execution, as sp_instr_copen saw that the
    query is already "EXECUTED" and therefore either not ran first-execution 
    related blocks or wrongly rolled back the transformations caused by 
    first-execution code.
    The fix is to update the state of the parsed tree only when the tree is
    executed, as opposed to when the instruction containing the tree is executed.
    Assignment if i->state is moved to reset_lex_and_exec_core.
    
    
    mysql-test/r/sp.result:
      Test results fixed (Bug#15217)
    mysql-test/t/sp.test:
      Add a test case for Bug#15217
    sql/sp_head.cc:
      Move assignment of stmt_arena->state to reset_lex_and_exec_core
    67fd3c4a
sp_head.cc 87 KB