MySQL Bugs: #30999: Killed InnoDB transaction gets into binary log then stops replication slaves

Bug #30999	Killed InnoDB transaction gets into binary log then stops replication slaves
Submitted:	13 Sep 2007 12:36	Modified:	21 Oct 2007 12:49
Reporter:	James Day	Email Updates:
Status:	Can't repeat	Impact on me:	None
Category:	MySQL Server: Replication	Severity:	S2 (Serious)
Version:	5.0.41	OS:	Linux (Linux nj-ckmd-01 2.6.9-55.ELsmp #1 SMP Fri Apr 20 16:36:54 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux )
Assigned to:	James Day	CPU Architecture:	Any
Tags:	bfsm_2007_10_18

Description:
A killed InnoDB transaction was saved to the binary log then relayed to a slave where the slave stopped with "Slave: Query caused different errors on master and slave. Error on master: 'Query execution was interrupted' (1317), Error on slave: 'no error' (0)". It's expected that killing a change to a non-transactional engine will have this result, but I don't expect it for a transactional engine.

How did a killed InnoDB transaction make it to the binary log with error 1317?

Initially assigned to Mats for his opinion on whether this may be related to bug #26551 .

How to repeat:
See private comment that follows.

test case

Attachment: bug30999.java (text/plain), 1.69 KiB.

Thank you for the report.

I can not repeat described behaviour with version 5.0.45 and current development sources, although bug is repeatable with version 5.0.41.

5.0.45 binary log:

<snip>
# at 2498
#071021 14:46:26 server id 1  end_log_pos 381   Query   thread_id=5     exec_time=5     error_code=0
SET TIMESTAMP=1192970786/*!*/;
INSERT INTO cookie (cookie_type_id, cookie_value, plf_code, active_flag, creation_date_time, mod_date_time,num_days_expiration)VALUES(2,'3a424501d07149e0bb815984aebc82a0','PCLN','Y','2007-08-28 15:08:50','2007-08-28 15:08:50',sleep(20)+365) ON DUPLICATE KEY UPDATE cookie_id = cookie_id/*!*/;
# at 2851
#071021 14:46:26 server id 1  end_log_pos 2878  Xid = 38
COMMIT/*!*/;
DELIMITER ;
# End of log file
ROLLBACK /* added by mysqlbinlog */;
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;

This appears to have been fixed in 5.0.44 by either the fix for bug #12826 or bug #26842. If the former, the root cause may be an application using a user variable in the same statement in which it is set.