Re: Suggestion to add --continue-client-on-abort option to pgbench
Chao Li <li.evan.chao@gmail.com>
From: Chao Li <li.evan.chao@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Rintaro Ikeda <ikedarintarof@oss.nttdata.com>,
Yugo Nagata <nagata@sraoss.co.jp>,
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-11-07T00:06:32Z
Lists: pgsql-hackers
> On Nov 7, 2025, at 00:38, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Thu, Nov 6, 2025 at 8:38 AM Chao Li <li.evan.chao@gmail.com> wrote:
>> I just eyeball reviewed v20 and got a doubt:
>
> Thanks for the review!
>
>
>> +static void
>> +discardAvailableResults(CState *st)
>> +{
>> + PGresult *res = NULL;
>> +
>> + for (;;)
>> + {
>> + res = PQgetResult(st->con);
>> +
>> + /*
>> + * Read and discard results until PQgetResult() returns NULL (no more
>> + * results) or a connection failure is detected. If the pipeline
>> + * status is PQ_PIPELINE_ABORTED, more results may still be available
>> + * even after PQgetResult() returns NULL, so continue reading in that
>> + * case.
>> + */
>> + if ((res == NULL && PQpipelineStatus(st->con) != PQ_PIPELINE_ABORTED) ||
>> + PQstatus(st->con) == CONNECTION_BAD)
>> + break;
>> +
>> + PQclear(res);
>> + }
>> + PQclear(res);
>> +}
>> ```
>>
>> If pipeline is aborted and no more results, then the “if” will be "true && false”. And in this case, I guess PQstatus(st->con) != CONNECTION_BAD because it’s not a connection error, then overall, the “if” will be “false”, and it falls into an infinite loop.
>
> Can this situation actually happen? It would be helpful if you could share
> the custom script that triggers it.
No, I don’t have such a script. I am on vacation and traveling with my family this week, I just found a little time to work on the day, that was why I only did an eyeball review.
>
> When the pipeline is aborted, PGRES_PIPELINE_SYNC should arrive afterward,
> changing the status from PQ_PIPELINE_ABORTED to PQ_PIPELINE_ON. That should
> make the condition true and prevent an infinite loop, right?
>
If you put this explanation to the inline comment, things would get clearer. But based on this explanation, I just got the other doubt. When a pipeline is aborted, res is NULL, but we still stay in the for loop, PQClear(res) will do nothing, then the “for” loop is similar to an empty loop, would that lead to a high CPU usage? From this perspective, when pipeline is aborted, while waiting for PIPELINE_SYNC, adding a tiny sleep might be better.
I will back to work next Monday, then I will try to run a test and reproduce the scenario of pipeline abort.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
pgbench: Fix assertion failure with multiple \syncpipeline in pipeline mode.
- 5bc251b28839 17.8 landed
- 00e64e35c8bd 18.2 landed
- 4aa0ac05765e 19 (unreleased) landed
-
pgbench: Add --continue-on-error option.
- 0ab208fa505c 19 (unreleased) landed
-
Fix "inconsistent DLL linkage" warning on Windows MSVC
- a3ea5330fcf4 19 (unreleased) cited
-
pgbench: Fix error reporting in readCommandResponse().
- 7d7e81d1e6b8 13.23 landed
- cb21e1f92fb3 14.20 landed
- bdccb6302871 15.15 landed
- 36c4d30c8f24 16.11 landed
- a912118c6055 17.7 landed
- 29aabbc43269 18.1 landed
- 19d4f9ffc207 19 (unreleased) landed
-
pgbench: Fix assertion failure with retriable errors in pipeline mode.
- 704f517711b4 15.15 landed
- 8b2e290bde21 16.11 landed
- f39d9164b70a 17.7 landed
- c736808e03b7 18.1 landed
- 8bb174295e89 19 (unreleased) landed
-
Allow pgbench to retry in some cases.
- 4a39f87acd6e 15.0 cited