Bug#38540 rpl_server_id2 uses show slave status unnecessarily
Slave did not perform any event recorded into the relay log from some
different master when it was started with --replicate-same-server-id.
The reason appeared to be a consequence of BUG#38734 which stopped the
sql thread at its startup time.
The real fixes for the current bug are in the patch for BUG#38734.
This changeset carries only a regression test for the bugs. Bug#38540
gets fixed too by means of eliminating an extra show slave status.
BUG#39382: innodb_max_dirty_pages_pct_func failed with timeout on pushbuild
Disabled innodb_max_dirty_pages_pct_func.
Please re-enable if the test gets fixed.
If before running test rpl_mulit_engin, the mysqltest1 database exists
on master but not exists on slave, then the following statement:
create database if not exists mysqltest1;
would not be logged to binary log, and so the database would not be
created on slave. This would cause the test to fail and reporting
mysqltest1 database not existed on slave.
This patch fixed this problem by not using a different database for
the whole test, just use the default test database, there is no reason
why a seperate database is used for this test.
1. mysqltest.cc - added flush to log file after each executed command in a testcase.
2. mtr shows 20 last lines from test case log file if timeout reached.
3. Optimizing the code by Magnus review.
4. It is partially fix bug#40150
- Change the logic slightly for when and how errors from
check-warnings and check-testcase are reported. The prevoius logic
reporting testfailed twice and that might have caused this.
- Also print result code returned from mysqltest when it is "unexpected"
Problem: Many test cases don't clean up after themselves (fail
to drop tables or fail to reset variables). This implies that:
(1) check-testcase in the new mtr that currently lives in
5.1-rpl failed. (2) it may cause unexpected results in
subsequent tests.
Fix: make all tests clean up.
Also: cleaned away unnecessary output in rpl_packet.result
Also: fixed bug where rpl_log called RESET MASTER with a running
slave. This is not supposed to work.
Also: removed unnecessary code from rpl_stm_EE_err2 and made it
verify that an error occurred.
Also: removed unnecessary code from rpl_ndb_ctype_ucs2_def.
Problem 1: BUG#36625: rpl_redirect doesn't do anything useful. It tests an
obsolete feature that was never fully implemented.
Fix 1: Remove rpl_redirect.
Problem 2: rpl_innodb_bug28430 and rpl_flushlog_loop are disabled despite the
bugs for which they were disabled have been fixed.
Fix 2: Re-enable rpl_innodb_bug28430 and rpl_flushlog_loop.
The convert_constant_item function converts a constant to integer using
field for condition like 'field = a_constant'. In some cases the
convert_constant_item is called for a subquery when outer select is already
being executed, so convert_constant_item saves field's value to prevent its
corruption. For EXPLAIN and at the prepare phase field's value isn't
initialized yet, thus when convert_constant_item tries to restore saved
value it fails assertion.
Now the convert_constant_item doesn't save/restore field's value if it's
haven't been read yet. Outer constant values are always saved.
order by
Problem was that the first index read was unordered,
and the next was ordered, resulting in use of
uninitialized data.
Solution was to use the correct variable to see if
the 'next' call should be ordered or not.
Bug#39848 events_bugs fails sporadically on pushbuild
(missing rows in table event_log)
Details: Reimplement the subtest for BUG 28924
- check if the number of rows within the table
event_log changes but don't print rows
because the number varies depending on
load on testing box
- shift DROP USER befor DROP EVENT
= Subtest fits again to old bug
- remove no more needed comments + variables
Bug#39863 events_bugs fails sporadically on pushbuild
(extra processes in I_S.PROCESSLIST)
Details: Abort with appropriate message to the protocol if
release_lock() does not has the intended effect.
This cannot prevent problems caused by the probably
buggy release_lock() but it reveals if we had a
problem in this area.
Bug#39978 main.events_bugs does not clean up
Detail: Restore global.event_scheduler = ON at end of test
Bug#39569 events_bugs fails sporadically on pushbuild
(should have failed with errno 1539)
Detail: Set $wait_timeout to 4 instead of 2
- Fix two instabilities (result sets pulled from processlist in
subtest for bug 16407) which were found during tests with high
parallel I/O load
- Minor improvements of formatting
Details:
- Add comments
- Remove tabs and trailing blanks
- Add line breaks for better readability