MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:horst hunger Date:February 4 2009 10:41am
Subject:Re: bzr commit into mysql-6.0-bugteam branch (horst:3007) Bug#39937
View as plain text  
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


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