• Konstantin Osipov's avatar
    A fix and a test case for Bug#47648 "main.merge fails sporadically". · 5f9ac42b
    Konstantin Osipov authored
    If a prepared statement used both a MyISAMMRG table and a stored 
    function or trigger, execution could fail with "No such table"
    error or crash. 
    The error would come from a failure of the MyISAMMRG engine
    to meet the expectations of the prelocking algorithm, 
    in particular maintain lex->query_tables_own_last pointer
    in sync with lex->query_tables_last pointer/the contents
    of lex->query_tables. When adding merge children, the merge
    engine would extend the table list. Then, when adding 
    prelocked tables, the prelocking algorithm would use a pointer
    to the last merge child to assign to lex->query_tables_own_last.
    Then, when merge children were removed at the end of
    open_tables(), lex->query_tables_own_last
    was not updated, and kept pointing
    to a removed merge child.
    
    The fix ensures that query_tables_own_last is always in
    sync with lex->query_tables_last.
    
    This is a regression introduced by WL#4144 and present only
    in next-4284 tree and 6.0.
    
    mysql-test/r/merge.result:
      Update results (Bug#47648).
    mysql-test/t/merge.test:
      Add a test case for Bug#47648.
      Update the result file to reflect a fix of another bug
      in MyISAMMRG code: not maintaining lex->query_tables_own_last
      allowed a stored function or trigger to modify a merge table
      which was already updated by the main statement.
      It is not allowed for other storage engines, and should
      not be allowed for MyISAMMRG.
    storage/myisammrg/ha_myisammrg.cc:
      When adding children to the list of tables to open,
      make sure that we properly set lex->query_tables_own_last.
      When removing the children, update lex->query_tables_own_last
      if necessary.
    5f9ac42b
ha_myisammrg.cc 50.1 KB