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.
- 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
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.
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.
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.
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.
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.
VARIABLE_VALUE field is decreased to 1024 symbols.
(affected I_S tables: GLOBAL_VARIABLES, SESSION_VARIABLES,
GLOBAL_STATUS, SESSION_STATUS).
The only variable which can be longer than 1024 is
init_connect. The variable will be truncated with warning.
Additional fix:
Added where condition filter which speed up queries which
have where condition with expressions which use VARIABLE_NAME
field.
changed 'charset', 'collation' field length from 64 to MY_CS_NAME_SIZE(32)
in tables:
SCHEMATA, TABLES, COLUMNS, CHARACTER_SETS,
COLLATIONS, COLLATION_CHARACTER_SET_APPLICABILITY
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 partitioning clause is only a very long single line, which is very
hard to interpret for a human. This patch breaks the partitioning
syntax into one line for the partitioning type, and one line per
partition/subpartition.
According to documenation:
http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-replication-issues.html
When setting up circular replication for clusters with different
SQL nodes in each cluster used as replication master and slave,
SQL nodes must not start with --log-slave-updates option.
This patch fixed the test case by remove log-slave-updates
configuration from test case configuration file.
