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.