MySQL Lists are EOL. Please join:

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