Re: BUG #19494: Error on transaction commit inside pipeline triggers psql's Assert

On Tue, May 26, 2026 at 07:00:01PM +0000, PG Bug reporting form wrote:
> The following psql script:
> CREATE TABLE t(a INTEGER PRIMARY KEY DEFERRABLE INITIALLY DEFERRED);
> \startpipeline
> INSERT INTO t VALUES ($1), ($1) RETURNING * \bind 1 \sendpipeline
> \endpipeline
>
> psql: common.c:1503: discardAbortedPipelineResults: Assertion
> `pset.available_results > 0' failed.

That's one assertion, and with a bit more imagination for a deferred
constraint, I can trigger a second one for the number of syncs when at
the end of a pipeline:
\startpipeline
INSERT INTO pipeline_defer_tab VALUES ($1), ($1) \bind 1 \sendpipeline
\syncpipeline
SELECT 1 \bind \sendpipeline
\endpipeline

#5 0x000000000041bb0a in ExecQueryAndProcessResults (query=0x5db560
"SELECT 1 ", elapsed_msec=0x7fffffffc660, svpt_gone_p=0x7fffffffc65f,
is_watch=false, min_rows=0, opt=0x0, printQueryFout=0x0) at
common.c:2190
2190 Assert(pset.piped_syncs == 0);
(gdb) p pset.piped_syncs
$1 = 1

I am completely sure yet, but it looks like we will need to be smarter
with the handling of the number of piped commands by tracking them
across the syncs in the shape of a queue, or something like that? So
it feels like we need to think harder about the tracking of this
activity depending on the state of the pipeline we're in. Or we could
lift some of these assertions, but that would not be right to me.
--
Michael