cause ROLLBACK of statement", part 1. Review fixes.
Do not send OK/EOF packets to the client until we reached the end of
the current statement.
This is a consolidation, to keep the functionality that is shared by all
SQL statements in one place in the server.
Currently this functionality includes:
- close_thread_tables()
- log_slow_statement().
After this patch and the subsequent patch for Bug#12713, it shall also include:
- ha_autocommit_or_rollback()
- net_end_statement()
- query_cache_end_of_result().
In future it may also include:
- mysql_reset_thd_for_next_command().
without PK
Bug#31609 Not all RBR slave errors reported as errors
bug#32468 delete rows event on a table with foreign key constraint fails
The first two bugs comprise idempotency issues.
First, there was no error code reported under conditions of the bug
description although the slave sql thread halted.
Second, executions were different with and without presence of prim key in
the table.
Third, there was no way to instruct the slave whether to ignore an error
and skip to the following event or to halt.
Fourth, there are handler errors which might happen due to idempotent
applying of binlog but those were not listed among the "idempotent" error
list.
All the named issues are addressed.
Wrt to the 3rd, there is the new global system variable, changeble at run
time, which controls the slave sql thread behaviour.
The new variable allows further extensions to mimic the sql_mode
session/global variable.
To address the 4th, the new bug#32468 had to be fixed as it was staying
in the way.
ha_partition::update_create_info() just calls update_create_info
of a first partition, so only get the autoincrement maximum
of the first partition, so SHOW CREATE TABLE can show
small AUTO_INCREMENT parameters.
Fixed by implementing ha_partition::update_create_info() in a way
other handlers work.
HA_ARCHIVE:stats.auto_increment handling made consistent with other engines
When executing drop view statement on the master, the statement is not written into bin-log if any error occurs, this could cause master slave inconsistence if any view has been dropped.
If some error occured and no view has been dropped, don't bin-log the statement, if at least one view has been dropped the query is bin-logged possible with an error.
In BUG#30244 added FOUND_ROWS() as an unsafe function, but that
works only in mixed mode under 5.1. There is a workaround that
can be used in statement-based mode either under 5.0 or 5.1
where the result of FOUND_ROWS() is stored into a user vari-
able and used that way instead. This will replicate correctly
even under statement-based replication, since it will write
a User_var entry to the binary log. For some other cases, the
value has to be passed explicitly.
This patch adds tests to demonstrate that the workarounds docu-
mented for statement-based replication works as advertised, and
does more extensive tests for cases that does not work under sta-
tement-based replication actually work under mixed mode by switch-
ing to row-based replication.
Actually, the failure happened with 3innodb as well. Most probably
the reason is in failing to delete a binlog file on __NT__ so that
that master increments the index of the binlog file.
The test results hide valueable warning that windows could generate
about that.
The scope of this fix is to make sure we have such warning and
to lessen chances for binlog file being held at time of closing.
The dump thread is getting a good chance to leave and
release the file for its successful deletion.
We shall watch over the two tests as regression is not excluded.
In that case we would have an extra info possibly explaining why
__NT__ env can not close/delete the file.
However, regardless of that reason, there is alwasy workaround to mask out
non-deterministic binlog index number.
Marking statements containing USER() or CURRENT_USER() as unsafe, causing
them to switch to using row-based logging in MIXED mode and generate a
warning in STATEMENT mode.
The rpl_trigger test case indicated a problem with idempotency support when run
under row-based replication, which this patch fixes.
However, despite this, the test is not designed for execution under row-based
replication and hence rpl_trigger.test is not executed under row-based
replication.
The problem is that the test expects triggers to be executed when the slave
updates rows on the slave, and this is (deliberately) not done with row-based
replication.
replication):
Incremental patch to enable idempotency support for update events again.
The final handling of errors will be done in BUG#31609, and until then
the handling of errors should be consistent between the different types
of changes.
Non-determinism in the tests was due to results of SBR are different from those gained
with row binlog format.
Because tests effectively verify skipping only ER_DUP_ENTRY it is explicitly required
to run the test on in mixed and stmt binlog format.
ER_DUP_ENTRY is automatically ignored when happened in RBR because of implicit rule
favoring reentrant reading from binlog rule
which means that a Write_rows_log_event overwrites a slave's row
if the one has the same primary key.
If future we might have skipping error due to applying of row-based events.
The comments added saying a new file would be needed for that: rpl_row_skip_error or smth.
If a temporary error occured inside a group on an event that was not the first
event of the group, the slave could get stuck because the retry counter is reset
whenever an event was executed successfully.
This patch only reset the retry counter when an entire group has been successfully
executed, or failed with a non-transient error.
When replicating an update pair (before image, after image) under row-based
replication, and the before image is not found on the slave, the after image
was not discared, and was hence read as a before image for the next row.
Eventually, this lead to an after image being read outside the block of rows
in the event, causing an assertion to fire.
This patch fixes this by reading the after image in the event that the row
was not found on the slave, adds some extra debug assertion to catch future
errors earlier, and also adds a few non-debug checks to prevent reading
outside the block of the event.
is possible):
When skipping the beginning of a transaction starting with BEGIN, the OPTION_BEGIN
flag was not set correctly, which caused the slave to not recognize that it was
inside a group. This patch sets the OPTION_BEGIN flag for BEGIN, COMMIT, ROLLBACK,
and XID events. It also adds checks if inside a group before decreasing the
slave skip counter to zero.
Begin_query_log_event was not marked that it could not end a group, which is now
corrected.
