Query_log_event::error_code
A query can perform completely having the local var error of mysql_$query
zero, where $query in insert, update, delete, load,
and be binlogged with error_code e.g KILLED_QUERY while there is no
reason do to so.
That can happen because Query_log_event consults thd->killed flag to
evaluate error_code.
Fixed with implementing a scheme suggested and partly implemented at
time of bug@22725 work-on. error_status is cached immediatly after the
control leaves the main rows-loop and that instance always corresponds
to `error' the local of mysql_$query functions. The cached value
is passed to Query_log_event constructor, not the default thd->killed
which can be changed in between of the caching and the constructing.
Documented some binlog events using doxygen. More will be done later.
Also fixed typos in other comments and added remarks about dubious code.
Only comments are affected, there is no change to the actual code.
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.
When doing indexed search the server constructs a key image for
faster comparison to the stored keys. While doing that it must not
perform (and stop if they fail) the additional date checks that can
be turned on by the SQL mode because there already may be values in
the table that don't comply with the error checks.
Fixed by ignoring these SQL mode bits while making the key image.
an error, asserts server
In case of a fatal error during filesort in find_all_keys() the error
was returned without the necessary handler uninitialization.
Fixed by changing the code so that handler uninitialization is performed
before returning the error.
Since, as of MySQL 5.0.15, CHAR() arguments larger than 255 are converted into multiple result bytes, a single CHAR() argument can now take up to 4 bytes. This patch fixes Item_func_char::fix_length_and_dec() to take this into account.
This patch also fixes a regression introduced by the patch for bug21513. As now we do not always have the 'name' member of Item set for Item_hex_string and Item_bin_string, an own print() method has been added to Item_hex_string so that it could correctly be printed by Item_func::print_args().
The value of the actual argument of BIT-type-arg stored procedure was binlogged as non-escaped
sequence of bytes corresponding to internal representation of the bit value.
The patch enforces binlogging of the bit-argument as a valid literal: prefixing the quoted bytes
sequence with _binary.
Note, that behaviour of Item_field::var_str for field_type() of MYSQL_TYPE_BIT is exceptional
in that the returned string contains the binary representation even though result_type() of
the item is INT_RESULT.
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.
The general log write function (general_log_print) uses printf style
arguments which need to be pre-processed, meaning that the all arguments
are copied to a single buffer and the problem is that the buffer size is
constant (1022 characters) but queries can be much larger then this.
The solution is to introduce a new log write function that accepts a
buffer and it's length as arguments. The function is to be used when
a formatted output is not required, which is the case for almost all
query write-to-log calls.
This is a incompatible change with respect to the log format of prepared
statements.
The server crashed when a thread was killed while locking the
general_log table at statement begin.
The general_log table is handled like a performance schema table.
The state of open tables is saved and cleared so that this table
seems to be the only open one. Then this table is opened and locked.
After writing, the table is closed and the open table state is
restored. Before restoring, however, it is asserted that there is
no current table open.
After locking the table, mysql_lock_tables() checks if the thread
was killed in between. If so, it unlocks the table and returns an
error. open_ltable() just returns with the error and leaves closing
of the table to close_thread_tables(), which is called at
statement end.
open_performance_schema_table() did not take this into account.
It assumed that a failed open_ltable() would not leave an open
table behind.
Fixed by closing thread tables after open_ltable() and before
restore_backup_open_tables_state() if the thread was killed.
No test case. It requires correctly timed parallel execution.
Since this bug was detected by the test suite, it seems
dispensable to add another test.
