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

On 18/07/18 01:43, Fabien COELHO wrote:
>>> The more reasonable alternative could be to always last 2 seconds under
>>> -T 2, even if the execution can be shorten because there is nothing to do
>>> at all, i.e. remove the environment-based condition but keep the sleep.
>>
>> That sounds reasonable. It's a bit silly to wait when there's nothing to do,
>> but it's also weird if the test exits before the specified time is up. Seems
>> less surprising to always sleep.
>
> I did that in the attached version: no more environment variable hack, and
> no execution shortcut even if there is nothing to do.
>
> I also had to reproduce the progress logic to keep on printing report of
> (no) progress in this tailing phase.

On second thoughts, there's one problem with this approach of always
waiting until -T is up. What if all the threads died because of errors?
For example:

pgbench postgres -T 10 -P 1 -c 2
starting vacuum...end.
client 0 aborted in command 5 (SQL) of script 0; ERROR: relation
"pgbench_accounts" does not exist
LINE 1: UPDATE pgbench_accounts SET abalance = abalance + -4963 WHER...
^

client 1 aborted in command 5 (SQL) of script 0; ERROR: relation
"pgbench_accounts" does not exist
LINE 1: UPDATE pgbench_accounts SET abalance = abalance + -2985 WHER...
^

progress: 1.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 2.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 3.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 4.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 5.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 6.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 7.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 8.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 9.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
progress: 10.0 s, 0.0 tps, lat 0.000 ms stddev 0.000
transaction type: <builtin: TPC-B (sort of)>
scaling factor: 1
query mode: simple
number of clients: 2
number of threads: 1
duration: 10 s
number of transactions actually processed: 0

I don't think you want to wait in that situation. I think we should wait
at the end only if there some threads still alive, with nothing to do
only because of --rate.

- Heikki