MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Rafal Somla Date:February 4 2009 12:08pm
Subject:Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937
View as plain text  
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;
>>>>>
>>>>>
>>>
>>>
> 
> 
Thread
bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937Horst Hunger3 Feb
  • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937Rafal Somla3 Feb
    • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937horst hunger5 Feb
    • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937horst hunger5 Feb
Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937Alfranio Correia3 Feb
  • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937horst hunger5 Feb
Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937Rafal Somla4 Feb
  • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937horst hunger5 Feb
  • Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937horst hunger5 Feb
Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937Rafal Somla4 Feb