Re: Suggestion to add --continue-client-on-abort option to pgbench

On Thu, 13 Nov 2025 22:55:53 +0900
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 could not reproduce it with the latest REL_16_STABLE branch.
Perhaps, the assertion failure you mentioned above was the one
fixed by 1d3ded521?
Or, I am missing something...

> I've also made a few cosmetic tweaks to the patch. Attached is the updated
> version, which I plan to push.

Thank you for updating the patch.

By the way, your prevous email has not been archived [1].
I guess it was not received by the server due to some issue.
Therefore, I've attached patches you've sent.

[1] https://www.postgresql.org/list/pgsql-hackers/since/202511130000/


-- 
Yugo Nagata <nagata@sraoss.co.jp>