Horton
Menu

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

Fujii Masao <masao.fujii@gmail.com>

View thread
From: Fujii Masao <masao.fujii@gmail.com>
To: Rintaro Ikeda <ikedarintarof@oss.nttdata.com>
Cc: Yugo Nagata <nagata@sraoss.co.jp>, Chao Li <li.evan.chao@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, "slpmcf@gmail.com" <slpmcf@gmail.com>, "boekewurm+postgres@gmail.com" <boekewurm+postgres@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, Srinath Reddy Sadipiralla <srinath2133@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>
Date: 2025-10-21T00:58:12Z
Lists: pgsql-hackers 
On Sun, Oct 19, 2025 at 10:12 PM Rintaro Ikeda
<ikedarintarof@oss.nttdata.com> wrote:
>
> Hi,
>
> On 2025/10/02 1:22, Fujii Masao wrote:
> > Regarding 0002:
> >
> > - if (canRetryError(st->estatus))
> > + if (continue_on_error || canRetryError(st->estatus))
> >   {
> >   if (verbose_errors)
> >   commandError(st, PQresultErrorMessage(res));
> >   goto error;
> >
> > With this change, even non-SQL errors (e.g., connection failures) would
> > satisfy the condition when --continue-on-error is set. Isn't that a problem?
> > Shouldn't we also check that the error status is one that
> > --continue-on-error is meant to handle?
>
> I agree that connection failures should not be ignored even when
> --continue-on-error is specified.
> For now, I’m not sure if other cases would cause issues, so the updated patch
> explicitly checks the connection status and emits an error message when the
> connection is lost.

I agree that connection failures should prevent further processing even with
--continue-on-error, and pgbench should focus on handling that first.
However, the patch doesn't seem to handle cases where the connection is
terminated by an admin (e.g., via pg_terminate_backend()) correctly.
Please see the following test case, which is the same one I shared earlier:

-----------------------------------------
$ cat pipeline.sql
\startpipeline
DO $$
  BEGIN
    PERFORM pg_sleep(3);
    PERFORM pg_terminate_backend(pg_backend_pid());
  END $$;
\endpipeline

$ pgbench -n -f pipeline.sql -c 2 -t 4 -M extended --continue-on-error
-----------------------------------------

In this case, PQstatus() (added in readCommandResponse() by the patch)
still returns CONNECTION_OK (BTW, the SQLSTATE is 57P01 in this case).
As a result, the expected error message like “client ... script ... aborted
in command ...” isn't reported. So the PQstatus() check alone that
the patch added doesn't fully fix the issue.

Regards,

-- 
Fujii Masao

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. pgbench: Fix assertion failure with multiple \syncpipeline in pipeline mode.

  2. pgbench: Add --continue-on-error option.

  3. Fix "inconsistent DLL linkage" warning on Windows MSVC

  4. pgbench: Fix error reporting in readCommandResponse().

  5. pgbench: Fix assertion failure with retriable errors in pipeline mode.

  6. Allow pgbench to retry in some cases.