Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" testpending solution of its timing is (fwd)

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