Re: Suggestion to add --continue-client-on-abort option to pgbench - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Suggestion to add --continue-client-on-abort option to pgbench
Date
Msg-id CAHGQGwGmLwdBPWNotZHjpaEhY-28-d4krbt5Q_S5-s-6Y5=2_A@mail.gmail.com
Whole thread Raw
In response to Re: Suggestion to add --continue-client-on-abort option to pgbench  (Yugo Nagata <nagata@sraoss.co.jp>)
Responses Re: Suggestion to add --continue-client-on-abort option to pgbench
List pgsql-hackers
On Thu, Sep 18, 2025 at 10:22 AM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> That makes sense. How about rewriting this like:
>
>  However, if the --continue-on-error option is specified and the error occurs in
>  an SQL command, the client does not abort and proceeds to the next
>  transaction regardless of the error. These cases are reported as "other failures"
>  in the output. Note that if the error occurs in a meta-command, the client will
>  still abort even when this option is specified.

How about phrasing it like this, based on your version?

----------------------------
A client's run is aborted in case of a serious error; for example, the
connection with the database server was lost or the end of script was reached
without completing the last transaction.  The client also aborts
if a meta-command fails, or if an SQL command fails for reasons other than
serialization or deadlock errors when --continue-on-error is not specified.
With --continue-on-error, the client does not abort on such SQL errors
and instead proceeds to the next transaction.  These cases are reported
as "other failures" in the output.  If the error occurs in a meta-command,
however, the client still aborts even when this option is specified.
----------------------------

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: Reword messages using "as" instead of "because"
Next
From: Amit Kapila
Date:
Subject: Re: How can end users know the cause of LR slot sync delays?