Replicated Trxs That Skip from Ignored Deadlock have Inconsistent Rollback

If replicating an event in ROW format, and InnoDB detects a deadlock while searching for a row, the row event will error and rollback in InnoDB and indicate that the binlog cache also needs to be cleared. In the normal case, this will trigger an error in Rows_log_event::do_apply_event() and cause a rollback. However, if the replica is configured to skip deadlock errors, the rows event logic will clear the error and continue on, as if no error happened. This results in everything before and up to the deadlocking statement rolling back, and everything after that statement (in the same transaction) to continue on and commit.

Instead, the later statements that occur within the transaction after the deadlock should be ignored as well.

The following patch and test will show the regression.

Patch (as git diff):

diff --git a/mysql-test/suite/rpl/t/rpl_temporary_error2.test b/mysql-test/suite/rpl/t/rpl_temporary_error2.test

index 3537499d562..5a2dd01c9ce 100644

--- a/mysql-test/suite/rpl/t/rpl_temporary_error2.test

+++ b/mysql-test/suite/rpl/t/rpl_temporary_error2.test

@@ -46,6 +46,7 @@ BEGIN;

 UPDATE t1 SET b=1 WHERE a=2;

 INSERT INTO t2 VALUES (1);

 UPDATE t1 SET b=1 WHERE a=4;

+INSERT INTO t2 VALUES (99);

 COMMIT;

 --save_master_pos

Test to run:

./mtr rpl.rpl_temporary_error2_skip_all

where the result length mismatch shows that the new insert goes through, whereas everything before it in the same transaction is rolled back:

@@ -28,6 +28,7 @@

 UPDATE t1 SET b=1 WHERE a=2;

 INSERT INTO t2 VALUES (1);

 UPDATE t1 SET b=1 WHERE a=4;

+INSERT INTO t2 VALUES (99);

 COMMIT;

 connection slave;

 connection con_temp1;

@@ -54,6 +55,7 @@

 SELECT * FROM t2 ORDER BY a;

 a

 1

+99

 retries

 0

 Last_SQL_Errno = '0'

Result length mismatch