Two minor fixes:
1. to make make test executes with mixed;
2. proper isolation of binlog_statement_insert_delayed
from others through reset master cleaning up binlog
todo: adapt this technique to other restarting for binlog tests
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.
doesn't find the column"
When a user was using 4.1 tables with VARCHAR column and 5.0 server
and a query that used a temporary table to resolve itself, the
table metadata for the varchar column sent to client was incorrect:
MYSQL_FIELD::table member was empty.
The bug was caused by implicit "upgrade" from old VARCHAR to new
VARCHAR hard-coded in Field::new_field, which did not preserve
the information about the original table. Thus, the field metadata
of the "upgraded" field pointed to an auxiliary temporary table
created for query execution.
The fix is to copy the pointer to the original table to the new field.
and its duplicate BUG#19057 "Test 'rpl_row_func003' fails on SuSE SLES9 x86".
It was an assertion failure, only in debug builds, not present
in released versions (nothing to document).
It happened when doing SHOW TABLE STATUS on an InnoDB table
having an auto_increment column, right after creating the table.
The test which would have caught this problem was disabled in
mid-April for another reason (how much I like tests disabled for
months...).
The problem was that during DROP TEMPORARY TABLE we tried to acquire
the name lock, though temporary tables belongs to one connection, and
no race is possible.
The solution is to not use table name locking while executing
DROP TEMPORARY TABLE.
- BUG#15934: Instance manager fails to work;
- BUG#18020: IM connect problem;
- BUG#18027: IM: Server_ID differs;
- BUG#18033: IM: Server_ID not reported;
- BUG#21331: Instance Manager: Connect problems in tests;
The only test suite has been changed
(server codebase has not been modified).
When a view was used inside a trigger or a function, lock type for
tables used in a view was always set to READ (thus making the view
non-updatable), even if we were trying to update the view.
The solution is to set lock type properly.
init_dumping now accepts a function pointer to the table or view specific init_dumping function. This allows both tables and views to use the init_dumping function.
