A fix and a test case for Bug#47648 "main.merge fails sporadically".

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.

0 files changed, 0 insertions, 0 deletions