Re: pgbench logging broken by time logic changes - Mailing list pgsql-hackers

From Fabien COELHO
Subject Re: pgbench logging broken by time logic changes
Date
Msg-id alpine.DEB.2.22.394.2106231125540.1117163@pseudo
Whole thread Raw
In response to Re: pgbench logging broken by time logic changes  (Michael Paquier <michael@paquier.xyz>)
Responses Re: pgbench logging broken by time logic changes
List pgsql-hackers
Bonjour Michaël,

> Could it be possible to document the intention of the test and its
> coverage then?  With the current patch, one has to guess what's the
> intention behind this case.

Ok, see attached.

>>> +check_pgbench_logs($bdir, '001_pgbench_log_1', $nthreads, 1, 3,
>>> +    qr{^\d{10,} \d{1,2} \d+ \d+ \d+ \d+ \d+ \d+ \d+ \d+ \d+$});
>
> Hm..  Could it be possible to tighten a bit the regex used here then?

> I was playing with it and it is not really picky in terms of patterns
> allowed or rejected.

> The follow-up checks for check_pgbench_logs() could be a bit more 
> restrictive as well, but my regex-fu is bad.

Given the probabilistic nature of a --rate run and the variability of 
hosts which may run the tests, it is hard to be more specific that \d+ for 
actual performance data. The run may try 0 or 50 transaction within a 
second (both with pretty low probabilities), so the test mostly checks the 
format and some basic sanity on the output and logs.

>>> I would say to give up on the first test, and keep the second.
>>
>> You mean remove the time check and keep the log check. I'd like to keep a
>> time check, or at least have it in comment so that I can enable it simply.
>
> I'd rather avoid tests that tend to fail on slow machines.  There is a
> flotilla in the buildfarm.

Commented out in attached v9.

-- 
Fabien.
Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: genbki stricter error handling
Next
From: Ajin Cherian
Date:
Subject: Re: [HACKERS] logical decoding of two-phase transactions