Hello Tom,
From my previous answer, to motivate these tests:
> The compromise I'm proposing is to skip time-related stuff if too slow. The
> value I see is that it provides coverage for all time-related features. I can
> also add a check that the run is *at least* 2 seconds when two seconds are
> asked for, because otherwise something was certainly amiss.
Also,
>> Hm. Could we get somewhere by making the test look for that, and
>> adjusting the loop logic inside pgbench so that (maybe only with the
>> tested switch values) it's guaranteed to print at least one progress
>> output regardless of timing, because it won't check for exit until after
>> it's printed a log message?
>
> I'll look into ensuring structuraly that at least one progress is shown.
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. The progress report generation is moved into a separate function,
which is an improvement of its own for the readability of threadRun.
Also, I have added a slight behavioral change when under tap testing
(through an environment variable) to avoid the end of processing shortcut
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.
All that is not perfect, but ISTM that having some minimal coverage of
time-related features is worth the compromise.
--
Fabien.
