The binlog_innodb test was sensitive to what tests ran before it. Now run
FLUSH STATUS before performing operations that need to be checked.
sys_var_thd_ulong::update() was improperly casting an option value from
ulonglong to ulong before comparing it to the max allowed value. On systems
where ulong and ulonglong are of different size, this caused values greater
than ULONG_MAX to wrap around (not be truncated to ULONG_MAX, which appears to
have been the intention of the original coder), and caused some checks to work
incorrectly. This wasn't generally visible to the user, because later checks
would prevent the wrapped-around value from being used. But it caused warning
messages to differ between 32- and 64-bit platforms. Fix is to just remove the
cast. Also added a DBUG_ASSERT to ensure that the value really is capped
properly before finally stuffing it into the ulong.
Disabled rpl_binlog_corruption since it requires the new mtr,
which only exists in 5.1-rpl / 6.0-rpl.
Please re-enable the test in 5.1-rpl / 6.0-rpl.
mysql-test/suite/rpl/t/disabled.def:
Disabled rpl_binlog_corruption since it requires the new mtr,
which only exists in 5.1-rpl / 6.0-rpl.
Problem: When an Incident_log_event contains a bad incident number on disk,
the server crashes with an assertion.
Fix: Don't validate input with assertions. Use errors.
mysql-test/include/cleanup_fake_relay_log.inc:
Added auxiliary file to restore things that setup_fake_relay_log.inc did.
mysql-test/include/setup_fake_relay_log.inc:
Added auxiliary file to setup replication from an existing relay log.
mysql-test/std_data/bug40482-bin.000001:
Binlog file for rpl.rpl_binlog_corruption
mysql-test/suite/rpl/t/rpl_binlog_corruption.test:
New test file.
sql/log_event.cc:
Check that the incident number is correct at the time the event is constructed.
Do not assert it at the time it is printed.
sql/log_event.h:
Incident_log_event::is_valid() should verify that the incident number is valid.
sql/rpl_constants.h:
Incident numbers should be hard-coded, since they may appear in files.
a minor improvement to the test to ease merging.
mysql-test/suite/rpl/r/rpl_server_id2.result:
results changed.
mysql-test/suite/rpl/t/rpl_server_id2.test:
masking out the until_pos which value is out of interest but
it presence hurts merging between trees.
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.
mysql-test/suite/rpl/r/rpl_server_id2.result:
Bug#38934 Bug#38540 changed results.
mysql-test/suite/rpl/t/disabled.def:
rpl_server_id2 is re-enabled.
mysql-test/suite/rpl/t/rpl_server_id2.test:
regression test for BUG#38734 is added.
Bug#38540 requirement to get rid of show slave status is implemented.
Static disabled plugins|engines and dynamic plugins which installed but disabled
are not visible in I_S PLUGINS|ENGINES tables because they are not stored into
global plugin array.
The fix: add such plugins|engines to plugin array with PLUGIN_IS_DISABLED status.
I_S.ENGINES 'Transactions', 'XA', 'Savepoints' fields have NULL value in this case.
mysql-test/r/warnings_engine_disabled.result:
test result
mysql-test/suite/funcs_1/r/is_columns_is.result:
result fix
mysql-test/suite/funcs_1/r/is_engines.result:
result fix
mysql-test/t/warnings_engine_disabled.test:
test case
sql/sql_plugin.cc:
store disabled plugins|engines into plugin array
sql/sql_plugin.h:
added PLUGIN_IS_DISABLED flag
sql/sql_show.cc:
added filling of 'engines'&'plugins' tables with disabled engines|plugins
exact number of error. The patch does following:
1) Add new parameter $slave_sql_errno for wait_for_slave_sql_error.inc
2) Add waiting error 1062 (Duplicate PK) for slave SQL thread in test case.
where timeout can happen:
1. Added waiting start/stop slave to make sure that slave works properly.
2. Added cleanup for slave.
3. Updated related result files.
binlog_row_mix_innodb_myisam resutls are corrected.
The last operations prior the dup error is
TRUNCATE table t2;
Therefore after
--error ER_DUP_ENTRY
INSERT INTO t2 select * from t1;
table t2 must be empty, and that is what the updated results confirm.
mysql-test/suite/binlog/r/binlog_row_mix_innodb_myisam.result:
results changed due to Bug #33420 fixing.
Extending bug#40221 regression test: 1. include INSERT 2. convert prim key + autoinc to
unique.
mysql-test/suite/binlog/r/binlog_innodb_row.result:
results changed.
mysql-test/suite/binlog/t/binlog_innodb_row.test:
Extending bug#40221 regression test to include the INSERT dup key errored-out case.
- remove totally wrong (syntax) entries from disabled.def
- remove entries belonging to deleted tests from disabled.def
- correct the comments (correct the bug mentioned) of entries in disabled.def
- remove never completed tests which were accidently pushed
Uncommited changes are replicated and stay on slave after
rollback on master
Making test slightly more generic and robust.
mysql-test/suite/rpl/t/rpl_trigger.test:
Adding code to check that InnoDB is available on slave as well.
Making code slightly more generic.
BUG#39325 Server crash inside MYSQL_LOG::purge_first_log halts replicaiton
The patch reverses the order of the purging and updating events for log and
relay-log.info/index files respectively.
This solves the problem of having holes caused by crashes happening between updating
info/index files and purging logs.
This patch also contains an aditional test case for testing the crashing before purge logs.
NOTE1: This is a combined patch for BUG#38826 and BUG#39325. This patch is based on
bugteam tree and takes into account reviewers suggestions.
NOTE2: Merge from 5.0-bugteam
'lock wait timeout exceeded'
Problem was a bug in the implementation of scan in partitioning
which masked the error code from the partition's handler.
Fixed by returning the value from the underlying handler.
mysql-test/suite/parts/r/partition_special_innodb.result:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Updated test result
mysql-test/suite/parts/t/partition_special_innodb.test:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Updated test case for covering the bug.
sql/ha_partition.cc:
Bug#40515: Query on a partitioned table does not return
'lock wait timeout exceeded'
Removing redeclaration of result variable,
which resulted in never returning the correct return value.
Altered param_check to disable warnings on system-sensitive operations
and added some notes / possible TODO
Re-recorded.result file to account for change
after rollback on master
When starting a transaction with a statement containing changes
to both transactional tables and non-transactional tables, the
statement is considered as non-transactional and is therefore
written directly to the binary log. This behaviour was present
in 5.0, and has propagated to 5.1.
If a trigger containing a change of a non-transactional table is
added to a transactional table, any changes to the transactional
table is "tainted" as non-transactional.
This patch solves the problem by removing the existing "hack" that
allows non-transactional statements appearing first in a transaction
to be written directly to the binary log. Instead, anything inside
a transaction is treaded as part of the transaction and not written
to the binary log until the transaction is committed.
mysql-test/suite/rpl/t/rpl_row_create_table.test:
Removing positions from SHOW BINLOG EVENTS and using
reset_master_and_slave to start on a fresh binary log each time.
mysql-test/suite/rpl/t/rpl_slave_skip.test:
Adding explicit commit in AUTOCOMMIT=0 to make test work correctly.
mysql-test/suite/rpl/t/rpl_trigger.test:
Adding test case for BUG#40116.
sql/log.cc:
Changing commit logic in binlog_commit() to only commit when
committing a real transaction or committing a punch transaction.
A transaction could result in having an extra event after a query that
errored e.g because of a dup key. Such a query is rolled back in
innodb, as specified, but has not been in binlog.
It appeares that the binlog engine did not always register for a query
(statement) because the previous query had not reset at its statement
commit time. Because of that fact there was no roll-back to the
trx_data->before_stmt_pos position and a the pending event of the
errorred query could become flushed to the binlog file.
Fixed with deploying the reset of trx_data->before_stmt_pos at the end
of the query processing.
mysql-test/suite/binlog/r/binlog_innodb_row.result:
a new test file to contain tests dealing with binlogging innodb with
the row-based format.
mysql-test/suite/binlog/t/binlog_innodb_row.test:
a new test file to contain tests dealing with binlogging innodb with
the row-based format.
sql/log.cc:
Flushing the pending row event at binlog_end_trans() is moved down to the commit
branch.
Resetting of trx_data->before_stmt_pos to the uninitialized value at the end of the
statement is implemented in binlog_commit() and binlog_rollback().
Asserting emptiness the transaction cache after reset() and the uninitilized value for the statement's savepoint binlog position.
The minimum value differs depending on the OS and mysqld build, so that the test fail spradically.
The check of this value has been changed from check of concrete values to the check of a range that is near by the expected value.
which were determined by the server depending on the os. The solution is to disable warnings in general.
The check of the values only have been done for Linux and Windows. Now, the check has been changed to the check of
ranges (not more concrete values) being near by the expected (set) values.
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.
mysql-test/include/rpl_multi_engine.inc:
use default test database instead of mysqltest1
mysql-test/suite/rpl/r/rpl_multi_engine.result:
use default test database instead of mysqltest1
mysql-test/suite/rpl/t/rpl_multi_engine.test:
use default test database instead of mysqltest1
add missing --enable_warnings
