The following is an excerption from the WL.
1. Change so that MIXED is default format
1.1 to change the default for command line --binlog-format
1.2 to alter global_system_variables.binlog_format calculation
basing on command line --binlog-format parameter and
its default.
2. Change test suite so that more testing is done by MIXED format.
2.1 to check if there are test cases requiring --binlog-foramt=statement via
`source include/have_binlog_format_statement.inc' and affected by
altering the latter to be "mixed".
2.2 to check the content of such vulnerable cases to find if
extending to the mixed does not modify results. In that case simply
substitute source arguments as explained.
2.3 if a test in mixed mode deals with features triggering
row-binlogging then if necessary we can switch explicitly
to statement mode or create another test to run with
non-recommended STATEMENT mode
Particullarily, extracting INSERT DELAYED
binlogging subtest for statement mode is performed, and
the snippet is moved into a separate test file.
Note that since now all three modes verify this use case
through 3 different tests.
No changes in item 3 of HLD appeared to be needed.
Fix for BUG#4971 "CREATE TABLE ... TYPE=HEAP SELECT ... stops slave (wrong DELETE in binlog)":
replacing the no_log argument of mysql_create_table() by some safer method
(temporarily setting OPTION_BIN_LOG to 0) which guarantees that even the automatic
DELETE FROM heap_table does not get into the binlog when a not-yet-existing HEAP table
is opened by mysql_create_table().
Note: The following tests fails
- fulltext (Sergei has promised to fix)
- rpl_charset (Guilhem should fix)
- rpl_timezone (Dimitray has promised to fix)
Sanja needs to check out the calling of close_thread_tables() in sp_head.cc
when we open the HEAP table for the first time since server restart,
in hp_open(), we set a flag to propagate this info to the handler level
which then writes a DELETE FROM this_heap_table to the binlog.
It is not a perfect solution for the bug, because between the server start and
the first open of the table, the slave still had old data in his table so
a SELECT on the slave may show wrong content. But if there is a --init-file
to populate the HEAP table on master as startup, then this is a safe fix
(I'll put a note about init-file in the HEAP section of the manual).
