Hi Andrei,
Thanks for this patch.
I'm not fully convinced that this will fix the bug. (This bug started to
show up after BUG#49978, but the problem you fix doesn't seem related to
BUG#49978.)
However, in any case it's a good idea to reduce the load. If the test
stops to fail after you have pushed, then you fixed the bug and
everything is fine. If there is another problem in the test then at
least you have optimized the test.
According to the comments in the test case, this test verifies that
replication works even when the SQL thread is 16 KB after the IO thread.
Hence:
- I don't think the load should depend on the platform.
- We can reduce the load even more, just to optimize the test.
It's enough that we generate a little more than 16 KB binlog
data. I tested and 100 rows is enough (it gives around 22 KB data).
- It would be good if the test checked that we actually generate
16 KB data.
So I will reject the patch and suggest to use something like this instead:
=== modified file 'mysql-test/suite/rpl/t/rpl_stm_000001.test'
--- mysql-test/suite/rpl/t/rpl_stm_000001.test 2010-12-19 17:15:12 +0000
+++ mysql-test/suite/rpl/t/rpl_stm_000001.test 2011-01-14 11:15:41 +0000
@@ -54,8 +54,9 @@ stop slave;
reset slave;
connection master;
-let $1=5000;
+let $1= 100;
# Generate 16K of relay log
+--let $pos= query_get_value(SHOW MASTER STATUS, Position, 1)
disable_query_log;
while ($1)
{
@@ -64,6 +65,11 @@ while ($1)
}
enable_query_log;
+# Check that we actually generated 16 KB data.
+--let $assert_text= We should have generated 16 KB relay log
+--let $assert_cond= [SHOW MASTER STATUS, Position, 1] - $pos > 16384
+--source include/rpl_assert.inc
+
# Try to cause a large relay log lag on the slave by locking t1
connection slave;
lock tables t1 read;
/Sven
On 12/29/2010 05:51 PM, Andrei Elkin wrote:
> #At file:///home/andrei/MySQL/BZR/2a-23May/mysql-trunk-bugfixing/ based on
> revid:dao-gang.qu@stripped
>
> 3475 Andrei Elkin 2010-12-29
> Bug #59205 Test rpl.rpl_stm_000001 fail on Valgrind with binlog-checksum
> enabled
>
> It was a timeout cause by logics of the test producing rather big volume of
> data.
>
> Adding a valgrind branch in the test having lesser load size so slow valgrind
> has
> a great chance to finish the test.
> @ mysql-test/suite/rpl/t/rpl_stm_000001.test
> decreasing the load size few times on the valgrid env.
> Notice, we seem could drop the general case load to the valgrind's value as
> well,
> if comments about 16k are relevant.
>
> modified:
> mysql-test/suite/rpl/t/rpl_stm_000001.test
> === modified file 'mysql-test/suite/rpl/t/rpl_stm_000001.test'
> --- a/mysql-test/suite/rpl/t/rpl_stm_000001.test 2010-12-19 17:15:12 +0000
> +++ b/mysql-test/suite/rpl/t/rpl_stm_000001.test 2010-12-29 16:51:30 +0000
> @@ -55,6 +55,12 @@ reset slave;
>
> connection master;
> let $1=5000;
> +
> +if (`SELECT $VALGRIND_TEST = 1`)
> +{
> + let $1= 1000;
> +}
> +
> # Generate 16K of relay log
> disable_query_log;
> while ($1)
>
>
>
>
>
