MySQL Bugs: #37230: no warnings clean up after applying rbr events with idemponent warnings

Bug #37230	no warnings clean up after applying rbr events with idemponent warnings
Submitted:	5 Jun 2008 16:41	Modified:	5 Jun 2008 17:20
Reporter:	Andrei Elkin	Email Updates:
Status:	Not a Bug	Impact on me:	None
Category:	MySQL Server: Row Based Replication ( RBR )	Severity:	S3 (Non-critical)
Version:	5.1	OS:	Any
Assigned to:	Andrei Elkin	CPU Architecture:	Any

Description:
When executing a scenario like in rpl_temporary_errors to generate a number of
idempotent warning, it was noticed that the slave sql thread aggregates the warnings instead of cleaning up the last one right before executing of the following row-based event.
In effect, the slave sql can waste a lot of memory.

How to repeat:
Use idea of rpl_temprorary_errors to create two rbr events to end up on slave
resultlessly but without the real failure; the slave is going to ignore the errors.

connection master;
SET SESSION BINLOG_FORMAT=ROW;
CREATE TABLE t1 (a INT PRIMARY KEY, b INT);
INSERT INTO t1 VALUES (1,1), (2,2), (3,3), (4,4);

connection slave;
set @@global.slave_exec_mode= 'IDEMPOTENT';
UPDATE t1 SET a = 5, b = 47 WHERE a = 1;

connection master;
UPDATE t1 SET a = 5, b = 5 WHERE a = 1;
UPDATE t1 SET a = 6, b = 6 WHERE a = 5;

sync_slave_with_master;

stop slave;

to see how the final farewell letter from the slave sql with lines
corresponding to two benign failures happened during slave run time
will appear in mysqld.err:

080605 19:36:08 [Warning] Slave SQL: Could not execute Update_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log master-bin.000001, end_log_pos 1266, Error_code: 1032
080605 19:36:08 [Warning] Slave SQL: Could not execute Update_rows event on table test.t1; Can't find record in 't1', Error_code: 1032; handler error HA_ERR_KEY_NOT_FOUND; the event's master log master-bin.000001, end_log_pos 1493, Error_code: 1032

Suggested fix:
Clean-up per bunch of Rows_log_event.

A correction. The lines had been appeared in the error log before slave got signalled to stop.
Still, those demonstrate with the slave sql is actually holding till the end. The fact that can be verified with reading the source code.

Clean-up actually exists so that no more than one warning can be in thd->warn_list. push_warning() provides that service to remove a slave warning.
Therefore, there is no thread of wasting memory.