From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
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 13:01:34 |
Message-ID: | alpine.DEB.2.21.1807180826260.11604@lancre |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hello Heikki,
>> 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:
Good corner-case catch! This behavior is indeed silly.
> 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.
Yep. The attached version does only the tailing stuff under -R and not all
threads were stopped on errors, with comments to tell about the why.
I'm still wondering about a specific option to explicitely require this
behavioral change.
--
Fabien.
Attachment | Content-Type | Size |
---|---|---|
pgbench-tap-progress-6.patch | text/plain | 11.0 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2018-07-18 13:06:22 | Re: [HACKERS] WAL logging problem in 9.4.3? |
Previous Message | Michael Paquier | 2018-07-18 13:01:09 | Re: PG 10: could not generate random cancel key |