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.
Fixing tests and results to work when replicating to fewer columns on
slave than on master. One test that previously should fail, now works,
and some log positions have changed as a result of adding metadata to
the events.
This patch adds the ability to store extra field metadata in the table
map event. This data can include pack_length() or field_lenght() for
fields such as CHAR or VARCHAR enabling developers to add code that
can check for compatibilty between master and slave columns. More
importantly, the extra field metadata can be used to store data from the
master correctly should a VARCHAR field on the master be <= 255 bytes
while the same field on the slave is > 255 bytes.
The patch also includes the needed changes to unpack to ensure that data
which is smaller on the master can be unpacked correctly on the slave.
WL#3915 : (NDB) master's cols > slave
Slave starts accepting and handling rows of master's tables which have more columns.
The most important part of implementation is how to caclulate the amount of bytes to
skip for unknown by slave column.
