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
