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

From: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
To: Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [HACKERS] Re: [COMMITTERS] pgsql: Remove pgbench "progress" test pending solution of its timing is (fwd)
Date: 2018-07-18 08:16:37
Message-ID: cc8f678d-53fd-75a7-c78e-34fb0c4e828b@iki.fi
Views: Raw Message | Whole Thread | Download mbox
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2018-07-18 08:18:18 Re: Incorrect error handling for two-phase state files resulting in data loss
Previous Message John Naylor 2018-07-18 08:13:20 Re: missing toast table for pg_policy