"Rows not deleted from innodb partitioned tables if --innodb_autoinc_lock_mode=0"
Due to a previous bugfix which initializes a previously uninitialized
variable, ha_partition::get_auto_increment() may fail to operate
correctly when the storage engine reports that it is only reserving
one value and one or more partitions have a different 'next-value'.
Currently, only affects Innodb's new-style auto-increment code which
reserves larger blocks of values and has less inter-thread contention.
"Regression: "--innodb_autoinc_lock_mode=0" (off) not same as older releases"
Bug#28430
"Failure in replication of innodb partitioned tables on row/mixed format"
Bug#30888
"Innodb table + stored procedure + row deletion = server crash"
Apply Oracle patch from Sunny
Include tests cases by Omer
Ensure that innobase_read_and_init_auto performs table autoinc lock when lock_mode = 0
No need for "if" guard around row_unlock_table_autoinc_for_mysql() because
it already performs same check.
Make autoinc_lock_mode variable read-only for duration of running mysqld process.
of statement breaks binlog.
There were two problems discovered by this bug:
1. Default (current) database is not fixed at the creation time.
That leads to wrong output of DATABASE() function.
2. Database attributes (@@collation_database) are not fixed at
the creation time. That leads to wrong resultset.
Binlog breakage and Query Cache wrong output happened because of
the first problem.
The fix is to remember the current database at the PREPARE-time and
set it each time at EXECUTE.
Bug#21422 GRANT/REVOKE possible inside stored function, probably in a trigger
Bug#17244 GRANT gives strange error message when used in a stored function
GRANT/REVOKE statements are non-transactional (no explicit transaction
boundaries) in nature and hence are forbidden inside stored functions and
triggers, but they weren't being effectively forbidden. Furthermore, the
absence of implict commits makes changes made by GRANT/REVOKE statements to
not be rolled back.
The implemented fix is to issue a implicit commit with every GRANT/REVOKE
statement, effectively prohibiting these statements in stored functions
and triggers. The implicit commit also fixes the replication bug, and looks
like being in concert with the behavior of DDL and administrative statements.
Since this is a incompatible change, the following sentence should be
added to the Manual in the very end of the 3rd paragraph, subclause
13.4.3 "Statements That Cause an Implicit Commit": "Beginning with
MySQL 5.0.??, the GRANT and REVOKE statements cause an implicit commit."
Patch contributed by Vladimir Shebordaev
The functions ROW_COUNT/FOUND_ROWS are indeed not safe to be used in
statement based replication.
Added code to declare them as such and switch the statement they're in
to row based logging for mixed mode.
MySQL replicates the time zone only when operations that involve
it are performed. This is controlled by a flag. But this flag
is set only on successful operation.
The flag must be set also when there is an error that involves
a timezone (so the master would replicate the error to the slaves).
A test case was waiting for a fixed number of seconds for a specific
state of the slave IO thread to take place.
Fixed by waiting in a loop for that specific thread state instead
(or timeout).
Changed patch to Mats suggestion from review. Patch is for Bug#30209
.del-wait_for_slave_running_off.inc:
Delete: mysql-test/include/wait_for_slave_running_off.inc
This patch adds functionality to row-based replication to ensure the
slave's column sizes are >= to that of the master.
It also includes some refactoring for the code from WL#3228.
Updated test to use new include function
wait_for_slave_running_off.inc:
Created new include to resolve the timing issue recorded by Bug#30209
rpl_events.inc:
The issue shown in Bug#30128 is that 'from er' shows up in a part of the test that it should not show up in. This event really is not created until later in the test, yet since the test runs row and then turns around and runs statement, I am guessing that the first run may not have cleaned up like it should, so I am adding a sync with master after the drop of table t1 to ensure that both master and slave are clean.
This patch corrects a problem found during testing on Solaris. The code
changes how length values are retrieved on big endian machines. The
patch allows the rpl_extraColmaster tests to run on these machines.
