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 CAHGQGwH_cEZA9n7AgvpErkR-kw5hi=RKhvR3vR8-OL_hojGqwA@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 Wed, Nov 12, 2025 at 6:34 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:
> I've attached an updated patch.

Thanks for updating the patch!

> The comment for the PQpipelineSync() call has been also updated to clarify
> why it is necessary.

+ /*
+ * If a PGRES_PIPELINE_SYNC is followed by something other than
+ * PGRES_PIPELINE_SYNC or NULL, another PGRES_PIPELINE_SYNC will
+ * eventually follow.
+ */

LGTM. I'd like to append "Reset received_sync to false to wait for
it." into this comment.


> In addition, I added a connection status check in the loop to avoid an
> infinte loop that waiting for PQpipelineSync after a connection failure.

Would it be better to move this status check right after PQgetResult()
so that connection failures can be detected regardless of what result
it returns?

+ pg_log_error("client %d aborted: the backend died while rolling back
the failed transaction after",

The trailing “after” seems unnecessary.

Since there's no guarantee the backend actually died in this case,
it might be better to use something like "client %d aborted while rolling back
the transaction after an error; perhaps the backend died while processing"
which matches the wording used under CSTATE_WAIT_ROLLBACK_RESULT
in advanceConnectionState().

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Yugo Nagata
Date:
Subject: Re: Suggestion to add --continue-client-on-abort option to pgbench
Next
From: Peter Smith
Date:
Subject: Re: [PATCH] Add pg_get_subscription_ddl() function