MySQL Bugs: #39013: rpl.rpl_filter_tables_not

Bug #39013	rpl.rpl_filter_tables_not_exist failed on pushbuild
Submitted:	25 Aug 2008 15:51	Modified:	6 Feb 2009 12:33
Reporter:	Sven Sandberg	Email Updates:
Status:	Closed	Impact on me:	None
Category:	Tests: Replication	Severity:	S7 (Test Cases)
Version:	6.0-rpl, 5.1	OS:	Any
Assigned to:	Serge Kozlov	CPU Architecture:	Any
Tags:	pushbuild, rpl_filter_tables_not_exist, test failure

Description:
pushbuild failure:

rpl.rpl_filter_tables_not_exist          [ fail ]

CURRENT_TEST: rpl.rpl_filter_tables_not_exist
--- /data0/pushbuild/pb2-1/pb/bzr_mysql-6.0-rpl/50/mysql-6.0.7-alpha-pb50/mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.result	2008-08-25 15:02:35.000000000 +0300
+++ /data0/pushbuild/pb2-1/pb/bzr_mysql-6.0-rpl/50/mysql-6.0.7-alpha-pb50/mysql-test/suite/rpl/r/rpl_filter_tables_not_exist.reject	2008-08-25 15:37:55.000000000 +0300
@@ -53,7 +53,7 @@
 include/start_slave.inc
 UPDATE t1 LEFT JOIN (t4, t7) ON (t1.id=t4.id and t1.id=t7.id) SET a=0 where t1.id=1;
 --source include/wait_for_slave_sql_error_and_skip.inc
-Last_SQL_Error = Error 'Table 'test.t4' doesn't exist' on query. Default database: 'test'. Query: 'UPDATE t1 LEFT JOIN (t4, t7) ON (t1.id=t4.id and t1.id=t7.id) SET a=0 where t1.id=1'
+Last_SQL_Error = Error 'Table 'test.t4' doesn't exist' on query. Default database: 'test'. Query: 'UPDATE t1 LEFT JOIN t4 ON (t1.id=t4.id) SET a=0 where t1.id=1'
 set global sql_slave_skip_counter=1;
 include/start_slave.inc
 UPDATE t1 LEFT JOIN (t2, t4, t7) ON (t1.id=t2.id and t1.id=t4.id and t1.id=t7.id) SET a=0, b=0 where t1.id=1;

mysqltest: Result content mismatch

 - saving '/dev/shm/var-ps_stm_threadpool-141/4/log/rpl.rpl_filter_tables_not_exist/' to '/dev/shm/var-ps_stm_threadpool-141/log/rpl.rpl_filter_tables_not_exist/'

Retrying test, attempt(2/3)...

How to repeat:
https://intranet.mysql.com/secure/pushbuild/showpush.pl?dir=bzr_mysql-6.0-rpl&order=50 'sles10-ia64-a' no innodb/ps_stm_threadpool

xref: http://tinyurl.com/646ed3

The test case contains following commands:

UPDATE something on master
source include/wait_for_slave_sql_error_and_skip.inc;

UPDATE something on master
source include/wait_for_slave_sql_error_and_skip.inc;

UPDATE something on master
source include/wait_for_slave_sql_error_and_skip.inc;

....

In this case SQL thread will stop with very similar error message for each block and if replication channel works slowly then "wait_for_slave_sql_error_and_skip.inc" will get error from previous block.
Fix should sync slave with master before every block and only then try check next block of code.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/62430

2756 Serge Kozlov	2008-12-30
      Bug#39013: 
      Added sync slave with master before every UPDATE on master to
      make sure that SQL error is not related to previous UPDATE statement.

After discuss with Zhenxing I agreed that my suggestions were wrong. The issue in "source" file "wait_for_slave_sql_error_and_skip.inc". This file does following:

wait a sql error;
wait stop of slave;
set skip counter;
start slave;

But start slave doesn't clear Last_SQL_Error field so 1st action from this file can be performed successfully for "old" errors too. Therefore the solution changes order of operations:

wait stop of slave;
check that sql error exists;
set skip counter;
start slave;

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/63558

2748 Serge Kozlov	2009-01-19
      Bug#39013:
      Fix the order of operation if the primitive. 
      The should to wait a stop of slave and only then
      check SQL error.

A patch for this bug has been committed. After review, it may
be pushed to the relevant source trees for release in the next
version. You can access the patch from:

  http://lists.mysql.com/commits/64047

2751 Serge Kozlov	2009-01-26
      Bug#39013:
      Fix the order of operation for the primitive wait_for_slave_sql_error_and_skip.inc.
      It should to wait stop of slave and only then check SQL error.

fixed with bug#37718

Changes were in tests only; no end-user changes to document. Closed.