Hornst,
That sounds fair to me.
R.
horst hunger wrote:
> 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;
>>>>>
>>>>>
>>>
>>>
>
>
