when --master-data is used
When using the --master-data option with mysqldump, mysqldump uses
a FLUSH TABLES command. However, this statement got replicated to
the slave(s), which caused the slave(s) to block unnecessarily while
the FLUSH tables command completed.
Now, if the master-data option is set to one of the two "on" modes,
then use the "LOCAL" qualifier to ensure that it's not replicated.
Make maximum blob size to be 2**32-1, regardless of word size.
Fix failure of timestamp with size of 2**31-1. The method of
rounding up to the nearest even number would overflow.
WL#4165 Prepared statements: validation
WL#4166 Prepared statements: automatic re-prepare
Fixes
Bug#27430 Crash in subquery code when in PS and table DDL changed after PREPARE
Bug#27690 Re-execution of prepared statement after table was replaced with a view crashes
Bug#27420 A combination of PS and view operations cause error + assertion on shutdown
The basic idea of the patch is to keep track of table metadata between
prepared statement prepare and execute. If some table used in the statement
has changed, the prepared statement is re-prepared before execution.
See WL#4165 and WL#4166 contents and comments in the code for details
of the implementation.
Among two claimed artifacts the critical one is in that the Table map of
a query following the failing with a duplicate key error CREATE-SELECT is skipped from
instantionating (and thus binlogging). That leads to sending a "chopped" group of the data
row-events without the table map head to the slave.
The slave can not apply the only data row events.
It's not easy to force the slave to react with an error in such a case (the second complaint
on the bug report), because the lack of a table Rows_log_event::do_apply_event the data row event
handler is a common situation which normally designates the event has to be filtered out
basing on the repliation do/ingore rules decision.
Fixed: table map creating and binlogging is restored via deploying the standard cleanup call in
select_create::abort().
No error is reported if by chance the table map was not been binlogged.
Leaving this out to resolve with considering how to combine the do/ingore rules with the situation
when erronoulsy the Table_map is not written to binlog.
Mtr restarts servers because an option file exist for slave.
The option file for slave forces to skip test.foo table for replication.
But really test case does not invlved test.foo table at all.
So option file can be removed and mtr will not restart servers for test case.
