Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd) - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)
Date
Msg-id alpine.DEB.2.21.1807130000070.27883@lancre
Whole thread Raw
In response to Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)  (Fabien COELHO <coelho@cri.ensmp.fr>)
List pgsql-hackers
>>> Indeed… but then throttling would not be tested:-) The point of the test
>>> is to exercise all time-related options, including throttling with a
>>> reasonable small value.
>> 
>> Ok. I don't think that's really worthwhile. If we add some code that only 
>> runs in testing, then we're not really testing the real thing. I wouldn't 
>> trust the test to tell much. Let's just leave out that magic environment 
>> variable thing, and try to get the rest of the patch finished.
>
> If you remove the environment, then some checks need to be removed, because 
> the 2 second run may be randomly shorten when there is nothing to do. If not, 
> the test will fail underterminiscally, which is not acceptable. Hence the 
> hack. I agree that it is not beautiful.
>
> The more reasonable alternative could be to always last 2 seconds under -T 2, 
> even if the execution can be shorten because there is nothing to do at all, 
> i.e. remove the environment-based condition but keep the sleep.

Yet another option would be to replace the env variable by an option, eg
"--strict-time", that would be used probaly only by the TAP test, but 
would be an available feature.

-- 
Fabien.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Temporary WAL segments files not cleaned up after an instancecrash
Next
From: Andrew Dunstan
Date:
Subject: Re: Vacuum: allow usage of more than 1GB of work mem