Bug #4380 One-row INSERT/UPDATE/DELETE needn't be binlogged as 'killed'
Submitted: 2 Jul 2004 14:26 Modified: 1 Aug 2004 17:00
Reporter: Guilhem Bichot Email Updates:
Status: Not a Bug Impact on me:
Category:MySQL Server: Replication Severity:S2 (Serious)
Version:4.0 OS:Any (all)
Assigned to: Guilhem Bichot CPU Architecture:Any

[2 Jul 2004 14:26] Guilhem Bichot
Presently, if a INSERT INTO T VALUES(1) is killed after inserting the row but before writing to the binlog (this murder can happen simply with 'mysqladmin shutdown'), the query will be written to the binlog with error code 1053, causing the slave to stop. But it does not make sense. A one-row query is never partially executed. If it's in the binlog it means it went 100% ok.
So it would be nicer to have, in INSERT/UPDATE/DELETE:
if (one_row_inserted and thd->killed)

How to repeat:
add some sleep() and do a KILL.

Suggested fix:
will fix it.
[2 Jul 2004 14:31] Guilhem Bichot
The same applies to other error codes than killed. As long as we reach the place where we write to the binlog, it means everything went all right, so we should in fact do:
if (only_one_row_inserted)
[1 Aug 2004 17:00] Guilhem Bichot
Hey Guilhem, you forgot one case when you wrote:
"A one-row query is never partially executed. If it's in the
binlog it means it went 100% ok."
Values inserted by a one-row query can depend on if the connection is killed, so the slave needs to stop in this case. Example:
INSERT INTO t VALUES(GET_LOCK("a", 10)); (if killed, NULL will be inserted)
So, not easily fixable. In the future:
- we'll feature row-level binary logging which will eliminate the problem
- even with query-level binary logging, we'll soon (4.1 or 5.0) feature graceful shutdown levels, so that a query is not killed by shutdown until it has completed its update (binlog write included), so the problem will not happen for shutdown anymore, only happen for an explicit KILL (which is very rare).