MDEV-6549, failing to update gtid_slave_pos for a transaction that was retried.
The bug was that in some cases, if a replicated transaction was rolled back due to deadlock, during the subsequent retry of that transaction, the gtid_slave_pos would _not_ be updated with the new GTID, leaving the GTID position of the slave incorrect. Fix this by ensuring during the retry that we clear the flag that marks that the GTID has already been recorded in gtid_slave_pos, so that the update of gtid_slave_pos will be done again during the retry. In the original bug, the symptom was an assertion due to OPTION_GTID_BEGIN not being cleared during the retry of the transaction. The reason was some code in handling of a COMMIT query event, which would not clear the flag when not recording a GTID in gtid_slave_pos. This commit also fixes that code to always clear the OPTION_GTID_BEGIN flag for clarity, though it is actually not possible for OPTION_GTID_BEGIN to become set unless a GTID is pending for update (after fixing the bug described above).
Showing
Please register or sign in to comment