Hello Heikki,
Thanks for having a look at this small patch which aim at improving
pgbench coverage.
>> How pgbenchs prints a progress if none were printed, or if the last
>> progress was over 0.5 seconds ago, so as to have kind of a catchup in the
>> end.
>
> I don't understand the 0.5 second rule. For the tests, we only need to ensure
> that at least one progress report is printed, right?
I'm not so sure;-) I do not want to trust the threadRun loop in case of
heavy load or whatever issue a run may encounter, so this approach ensures
that structurally there is always one output even of the whole loop went
very wrong.
It also adds a small feature which is that there is always a final
progress when the run is completed, which can be useful when computing
progress statistics, otherwise some transactions could not be reported in
any progress at all.
> Looking at the code as it exists, I think it already works like that,
> although it's by accident. Not sure though, and if we're going to rely on
> that, it makes sense to make it more explicit.
Yep.
Also, by default, when running under throttling for 2 seconds at 20 tps,
there is a slight chance that no transactions are scheduled and that
pgbench returns immediately, hence the added variable to ensure that it
lasts something anyway, and that some minimal reporting is always done
whatever.
>> when there is nothing to do. This ensures that the -T 2 tap test runs for
>> at least 2 seconds, whatever. If the host is overload it might be more,
>> but it cannot be less unless something was wrong.
>
> If you want to write a test that checks that a two-second test takes at least
> two seconds, can't you just not use throttling in that test?
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.
Attached is a rebase.
--
Fabien.
