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-27T09:13:53Z
Lists: pgsql-hackers

Attachments

On Tue, Oct 21, 2025 at 9:58 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> 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.

One approach to address this issue is to keep calling PQgetResult() until
it returns NULL, and then check the connection status when getSQLErrorStatus()
determines the error state. If the connection status is CONNECTION_BAD
at that point, we can treat it as a connection failure and stop processing
even when --continue-on-error is specified. Attached is a WIP patch
implementing this idea based on the v17 patch. It still needs more testing,
review, and possibly documentation updates.

Another option would be to explicitly list all SQLSTATE codes (e.g., 57P01)
that should prevent continued processing, even with --continue-on-error,
inside getSQLErrorStatus(). However, maintaining such a list would be
cumbersome, so I believe the first approach is preferable. Thought?

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.