Re: Suggestion to add --continue-client-on-abort option to pgbench

From: Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>
To: Rintaro Ikeda <ikedarintarof(at)oss(dot)nttdata(dot)com>
Cc: "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com>, "slpmcf(at)gmail(dot)com" <slpmcf(at)gmail(dot)com>, "boekewurm+postgres(at)gmail(dot)com" <boekewurm+postgres(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Srinath Reddy Sadipiralla <srinath2133(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench
Date: 2025-07-15 02:16:40
Message-ID: 20250715111640.f7f67d1a3761a539230e53c5@sraoss.co.jp
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Sun, 13 Jul 2025 23:15:24 +0900
Rintaro Ikeda <ikedarintarof(at)oss(dot)nttdata(dot)com> wrote:

> I noticed one small thing I’d like to discuss. I'm not sure that users clearly
> understand which aborted in the following error message, the client or the script.
> > pgbench: error: client 0 script 0 aborted in command ... query ...
>
> Since the code path always results in a client abort, I wonder if the following
> message might be clearer:
> > pgbench: error: client 0 aborted in script 0 command ... query ...

Indeed, it seems clearer to explicitly state that it is the client that
was aborted.

I've attached an updated patch that replaces the remaining message mentioned
above with a call to commandFailed(). With this change, the output in such
situations will now be:

"client 0 aborted in command 0 (SQL) of script 0; ...."

Regards,
Yugo Nagata

--
Yugo Nagata <nagata(at)sraoss(dot)co(dot)jp>

Attachment Content-Type Size
v8-0003-Improve-error-messages-for-errors-that-cause-clie.patch text/x-diff 2.6 KB
v8-0002-Rename-a-confusing-enumerator.patch text/x-diff 1.1 KB
v8-0001-Add-continue-on-error-option.patch text/x-diff 16.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Josh Innis 2025-07-15 02:49:40 ScanKeys passed to table_beginscan in SeqNext
Previous Message Michael Paquier 2025-07-15 00:55:54 Re: Support for 8-byte TOAST values (aka the TOAST infinite loop problem)