On 12/10/2018 21:22, Fabien COELHO wrote:
> No further remarks. I turned the patch as ready on the CF app.
Committed, thanks.
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Hello Peter,
The abort is by a client, but the code seems to only check the first
client of a thread. ISTM that if the second or later client abort it may
not be detected? Probably an intermediate aggregation at the thread level
is needed, or maybe a global variable, or as errors are counted so
On 10/08/2018 01:41, Fabien COELHO wrote:
> Your approach of not changing the output too much but changing the exit
> status and adding a warning may get through more easily.
>
> Note that there is some logic in distinguishing between different type of
> errors (before the bench start vs the ben
On Mon, Oct 01, 2018 at 11:29:19AM +0900, Michael Paquier wrote:
> On Fri, Aug 10, 2018 at 01:50:49PM +0200, Fabien COELHO wrote:
>> BTW, I have added this patch to the next CF:
>>
>> https://commitfest.postgresql.org/19/1751/
>
> The latest patch does not apply anymore. Peter, could you re
On Fri, Aug 10, 2018 at 01:50:49PM +0200, Fabien COELHO wrote:
> BTW, I have added this patch to the next CF:
>
> https://commitfest.postgresql.org/19/1751/
The latest patch does not apply anymore. Peter, could you rebase it?
--
Michael
signature.asc
Description: PGP signature
The attached patch changes this so that it exits with status 1 and also
prints a line below the summary advising that the results are incomplete.
BTW, I have added this patch to the next CF:
https://commitfest.postgresql.org/19/1751/
--
Fabien.
Hello Peter,
In pgbench, when an error occurs during a benchmark run (SQL error,
connection error, etc.) it just prints an error message and then
proceeds to print the run summary normally and exits with status 0. So
this is quite inconvenient, especially from a script.
Yep. I'm fine with c
