On 18/01/18 12:26, Fabien COELHO wrote:
>>> 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.
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?
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.
> The progress report generation is moved into a separate function,
> which is an improvement of its own for the readability of threadRun.
Agreed on that.
> 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.
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?
- Heikki