Rafal,
I have basically no objection, but let me discuss it with the QA guys
(Matthias, Patrick,...) as it seems to be a conceptual change and may be
a WL. If all agree then we can do it for all tests and publish it to the
developers.
Alright?
Horst
Rafal Somla schrieb:
> 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;
>>>>
>>>>
>>
>>
--
Regards
Horst
Horst Hunger
Sun Microsystems GmbH, QA Software Developer
Office: +49 30 321 03 466
Amtsgericht München: HRB161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring
