Bug #54301 rpl.rpl_stm_insert_delayed fails sporadically in trunk-merge

• Submitted: 7 Jun 2010 16:25
• Modified: 3 Sep 2010 17:29
• Reporter: Alexander Nozdrin
• Status: Closed
• Category: MySQL Server: Replication
• Severity: S1 (Critical)
• Version: Celosia (M3), Dahlia (M4)
• OS: Linux (x86_64 gcov)
• Assigned to: Libing Song
• CPU Architecture: Any
• Tags: pb2, sporadic, test failure

[7 Jun 2010 16:25] Alexander Nozdrin

Description:
rpl.rpl_stm_insert_delayed started to fail sporadically
in mysql-trunk-merge and mysql-next-mr-merge. It seems,
it started to happen after a patch for Bug#49741 was pushed
into trunk-merge on 2010-05-26 16:40:45. That's not
100% sure however.

Usually, first run of the test case fails,
then it passes twice.

The problem has been seen only on 'linux  x86_64 gcov' so far.

Symptoms:

rpl.rpl_stm_insert_delayed 'stmt'        [ fail ]
        Test ended at 2010-06-05 16:11:35

CURRENT_TEST: rpl.rpl_stm_insert_delayed
--- /export/home3/pb2/build/sb_2-None-1275743580.22/mysql-trunk-merge-gcov/mysql-test/suite/rpl/r/rpl_stm_insert_delayed.result	2010-06-05 16:25:25.000000000 +0300
+++ /export/home3/pb2/build/sb_2-None-1275743580.22/mysql-trunk-merge-gcov/mysql-test/suite/rpl/r/rpl_stm_insert_delayed.reject	2010-06-05 17:11:35.000000000 +0300
@@ -55,8 +55,8 @@
 Log_name	Pos	Event_type	Server_id	End_log_pos	Info
 master-bin.000002	#	Query	#	#	BEGIN
 master-bin.000002	#	Query	#	#	use `test`; INSERT DELAYED IGNORE INTO t1 VALUES(1)
-master-bin.000002	#	Query	#	#	use `test`; INSERT DELAYED IGNORE INTO t1 VALUES(1)
 master-bin.000002	#	Query	#	#	COMMIT
+master-bin.000002	#	Query	#	#	BEGIN
 select * from t1;
 a
 1

How to repeat:
Check out PB2, pages for mysql-trunk-merge and mysql-next-mr-merge.

[12 Jun 2010 3:05] Libing Song

fixed by the post patch for bug#49741
revision-id: [e-mail]-20100608022734-sq0em098gh2l17pi

[3 Sep 2010 17:29] Jon Stephens

Testing code only (see BUG#49741). No changelog entry required -- closed.