Hi Horst,
Now I see - you are saying that the stray "Quit" can come from connections which
were closed before the relevant part of the test, not con1 which is disconnected
after that part. That makes sense to me, although the last disconnect statement
before the relevant part is several lines back which makes this scenario not
very probable.
But I agree that doing this before the relevant part:
a) killing all active connections (except the default) and
b) waiting for them to quit
should fix the test if the above theory is true.
Another thing: we were discussing with Alfranio and Luis that it would be better
to remove any timeouts from the waiting loop. The rationale is that it is hard
to predict correct timeout value (think about this test being executed on
pb-valgrind). If waiting loop has no timeout, then the test can potentially hang
forever, but there is a global MTR timeout which will solve this. The advantage
of using the MTR timeout is that it can be set differently on different
platforms and that test will fail with [timeout] message giving more information.
I'm not going to require this change in your patch, but if you agree, I strongly
suggest that you remove the timeouts.
Rafal
horst hunger wrote:
> Hi Rafal,
> alright. Good, that you don't agree. I have another idea, that may fix
> the bug: I wait until the preceding disconnects will be ready. That may
> guarantee that alway the expected 9 queries will be executed (without a
> quit in between, that is cause due to the parallel execution of sessions).
> The poposed fix will follow (hopefully) this evening.
> Thanks
> Horst
> Rafal Somla schrieb:
>> Hi Horst,
>>
>> Your solution is based on the assumption that the wrong count (10
>> instead of 9) is caused by extra "Quit" query being counted in. But
>> I'm not totally convinced by this. Looking at the relevant place in
>> the test this is what happens there:
>>
>> ...
>> let $org_queries= `SHOW STATUS LIKE 'Queries'`;
>> SELECT f1();
>> CALL p1();
>> let $new_queries= `SHOW STATUS LIKE 'Queries'`;
>> --disable_log
>> let $diff= `SELECT
>> SUBSTRING('$new_queries',9)-SUBSTRING('$org_queries',9)`;
>> --enable_log
>> eval SELECT $diff;
>> disconnect con1;
>> ...
>>
>> Thus the test assumes that calling f1() and p1() results in 9 queries
>> being executed. How come that "Quit" is also executed? Note that the
>> connection is disconnected *after* getting the $new_queries number.
>>
>> Hence I'm afraid that your patch can hide a real problem we have here.
>> What do you say?
>>
>> Rafal
>>
>> Horst Hunger wrote:
>>> #At file:///work/bzr/mysql-6.0-39937/
>>>
>>> 3007 Horst Hunger 2009-02-03
>>> Fix for bug#39937: Set the disconnect_timeout to 30 seconds to
>>> have more time in case of lower performance and specified a weaker
>>> condition as sometime also a "Quit" is counted as query.
>>> modified:
>>> mysql-test/r/status.result
>>> mysql-test/t/status.test
>>>
>>> === modified file 'mysql-test/r/status.result'
>>> --- a/mysql-test/r/status.result 2009-01-30 14:13:39 +0000
>>> +++ b/mysql-test/r/status.result 2009-02-03 13:30:23 +0000
>>> @@ -231,9 +231,9 @@ f1()
>>> CALL p1();
>>> 1
>>> 1
>>> -SELECT 9;
>>> -9
>>> -9
>>> +SELECT 9 BETWEEN 9 AND 10;
>>> +9 BETWEEN 9 AND 10
>>> +1
>>> DROP PROCEDURE p1;
>>> DROP FUNCTION f1;
>>> DROP VIEW IF EXISTS v1;
>>>
>>> === modified file 'mysql-test/t/status.test'
>>> --- a/mysql-test/t/status.test 2009-01-30 14:13:39 +0000
>>> +++ b/mysql-test/t/status.test 2009-02-03 13:30:23 +0000
>>> @@ -103,7 +103,7 @@ drop table t1;
>>> #
>>>
>>> # Wait for at most $disconnect_timeout seconds for disconnects to
>>> finish.
>>> -let $disconnect_timeout = 10;
>>> +let $disconnect_timeout = 30;
>>>
>>> # Wait for any previous disconnects to finish.
>>> FLUSH STATUS;
>>> @@ -327,7 +327,8 @@ let $new_queries= `SHOW STATUS LIKE 'Que
>>> --disable_query_log
>>> let $diff= `SELECT
>>> SUBSTRING('$new_queries',9)-SUBSTRING('$org_queries',9)`;
>>> --enable_query_log
>>> -eval SELECT $diff;
>>> +# The number of queries must at least be 9, but ometimes a "Quit" is
>>> also counted.
>>> +eval SELECT $diff BETWEEN 9 AND 10;
>>> disconnect con1;
>>> connection default;
>>> DROP PROCEDURE p1;
>>>
>>>
>
>