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 CAHGQGwGHqwD+wvuyDSsee6b80wxj6P3=QbBRfhDMxap43yd8sg@mail.gmail.com
Whole thread Raw
In response to Re: Suggestion to add --continue-client-on-abort option to pgbench  (Chao Li <li.evan.chao@gmail.com>)
Responses Re: Suggestion to add --continue-client-on-abort option to pgbench
List pgsql-hackers
On Tue, Nov 11, 2025 at 11:49 AM Chao Li <li.evan.chao@gmail.com> wrote:
> I just did more tests on both pipeline mode and non-pipeline mode, I think the main purpose of
discardAvailableResults()is to drain results for pipeline mode. In non-pipeline mode, a NULL res indicates no more
resultto read; while in pipeline mode, when a pipeline is aborted, either a valid result or NULL could still be
returned,thus we need to wait until pipeline state switch to PQ_PIPELINE_OK. From this perspective, the current inline
commentis correct, but I feel it’s not clear enough. 

Thanks for working on this!

After reconsidering, I think the main goal here is to determine whether
the error causes a connection failure after it occurs.

If we can read and discard results without PQstatus() becoming CONNECTION_BAD
either until the end (in non-pipeline mode) or until the first sync point
after an error (in pipeline mode), that means the connection is still alive,
and processing can continue when --continue-on-error is specified.

The current function comments don’t mention this purpose enough,
so seems they should be updated to clarify that.

Regards,

--
Fujii Masao



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: another autovacuum scheduling thread
Next
From: Dean Rasheed
Date:
Subject: Re: minor error message enhance: print RLS policy name when only one permissive policy exists