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>