ROW_MYSQL_WHOLE_ROW" IN ROW0MYSQL.CC

ANALYSIS:
=========
Statements which called two stored routines, one of which
tried to create temporary table in InnoDB SE and then to
modify it and another routine simply read from the same
table, resulted in assertion failure when statement or mixed
binary log format were used.

The assertion has been triggered because SQL-layer passed to
InnoDB SE incorrect information about the operation type on
the temporary table in such cases.

The underlying issue lies in building the prelocking list in
such cases. The presence of CREATE TEMPORARY TABLE inside
the first of routines makes the server think that the table might
not exist thus it does not add it to the prelocking list in
this case. OTOH the usage of the same table in another
routine causes its addition to prelocking list with a lock
type indicating read access.

As a result, at prelocking stage we only see one table instance
in prelocking list which is marked as to be read. We pass
this information to SE by calling handler::store_lock()/
external_lock() as a side-effect of calling
mysql_lock_tables()). Later, when we try to access the same
table for modification from the first of routines, InnoDB
considers this as breach of contract and asserts. (The
actual assertion is about whether the whole row is to be
used for the operation or not and thus masked when
--binlog_format=row as we have to use the whole row in this
case anyway).

FIX:
====
Do not call handler::store_lock()/external_lock() for the
temporary tables in the extended prelocking list during
prelocking stage. Delay informing SE about operation being
perfomed (by calling handler::start_stmt()) till the point
when the table is accessed during the execution of
substatements.

Approved by:
Dmitry Lenev (dmitry.lenev@oracle.com)
Sivert Sorumgaard (sivert.sorumgaard@oracle.com)

Change-Id: I029f45662678f9fc5150f1ee2c7db33a11a59b67