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: Yugo Nagata <nagata@sraoss.co.jp>,
Rintaro Ikeda <ikedarintarof@oss.nttdata.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-11-14T07:44:38Z
Lists: pgsql-hackers
> On Nov 13, 2025, at 21:55, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Thu, Nov 13, 2025 at 4:09 PM Yugo Nagata <nagata@sraoss.co.jp> wrote:
>> Thank you for your review!
>> I've attached an updated patch reflecting your suggestion.
>
> Thanks for updating the patch! LGTM.
>
> You mentioned that the assertion failure could occur when using \syncpipeline,
> but it seems that multiple PGRES_PIPELINE_SYNC results can also appear
> even without it, which can still trigger the same issue. For example,
> I was able to reproduce the assertion failure in v16 (which doesn't support
> \syncpipeline) with the following setup:
>
> --------------------------------
> $ cat deadlock.sql
> \startpipeline
> select * from a order by i for update;
> select 1;
> \endpipeline
>
> $ cat deadlock2.sql
> \startpipeline
> select * from a order by i desc for update;
> select 1;
> \endpipeline
>
> $ psql -c "create table a (i int primary key); insert into a
> values(generate_series(1,1000));"
>
> $ pgbench -n -j 4 -c 4 -T 5 -M extended -f deadlock.sql -f deadlock2.sql
> ...
> Assertion failed: (res == ((void *)0)), function discardUntilSync,
> file pgbench.c, line 3479.
> --------------------------------
>
> So I've updated the commit message to clarify that while using \syncpipeline
> makes the failure more likely, it can still occur without it. Since the issue
> can also happen in v15 and v16 (which both lack \syncpipeline), I plan to
> backpatch the fix to v15. The failure doesn't occur in v14 because it doesn't
> support retriable error retries.
>
> I've also made a few cosmetic tweaks to the patch. Attached is the updated
> version, which I plan to push.
>
> Regards,
>
> --
> Fujii Masao
> <v4-0001-pgbench-PG15-PG16-Fix-assertion-failure-when-discarding-res.txt><v4-0001-pgbench-Fix-assertion-failure-when-discarding-res.patch>
I think I was misunderstanding that “\syncpipeline” would recover the transaction. Once the confusion is resolved, I think v4 patch is overall good. Only one small comment:
```
+ else if (received_sync && res == NULL)
{
- /*
- * PGRES_PIPELINE_SYNC must be followed by another
- * PGRES_PIPELINE_SYNC or NULL; otherwise, assert failure.
- */
- Assert(res == NULL);
-
/*
* Reset ongoing sync count to 0 since all PGRES_PIPELINE_SYNC
* results have been discarded.
@@ -3601,6 +3610,15 @@ discardUntilSync(CState *st)
PQclear(res);
break;
}
```
As we now add “res==NULL” to the “else if”, once entering "else if (received_sync && res == NULL)”, res must be NULL, so "PQclear(res);” should be deleted. Leaving it there doesn’t harm today, but is error-prone, because if in future someone removes “res==NULL” from the “else if”, it will lead to double memory free, because after “break”, PQclear(res) will be called again.
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