Feedback-ID: i0fe9450f:Fastmail
Date: Thu, 28 May 2026 12:51:38 +0900
From: Michael Paquier <michael@paquier.xyz>
To: exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #19494: Error on transaction commit inside pipeline triggers
 psql's Assert
Message-ID: <ahe7ylLcESTmnZfk@paquier.xyz>
References: <19494-97a86d84fee71c47@postgresql.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="yRRfwbsvs08O+S4M"
Content-Disposition: inline
In-Reply-To: <19494-97a86d84fee71c47@postgresql.org>
Archived-At: 
 <https://www.postgresql.org/message-id/ahe7ylLcESTmnZfk%40paquier.xyz>
Precedence: bulk


--yRRfwbsvs08O+S4M
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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=3D0x5db560
"SELECT 1 ", elapsed_msec=3D0x7fffffffc660, svpt_gone_p=3D0x7fffffffc65f,
is_watch=3Dfalse, min_rows=3D0, opt=3D0x0, printQueryFout=3D0x0) at
common.c:2190
2190 Assert(pset.piped_syncs =3D=3D 0);
(gdb) p pset.piped_syncs
$1 =3D 1=20

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

--yRRfwbsvs08O+S4M
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmoXu8oACgkQnvQgOdby
QH2gMQ/+Jpftq8HKQFrsY7HRWDn7Ao7p9SkbYmWrtmhTzYG04VlXrtfg5ABI+P3w
txH5ImREUGZLlLqe2GQ/KFcavvo9wZ3SC1FqovT2FEdnt4AAEbFV9htK44aQ/+TL
QdZTgXVi3gYtDXHkWhRVPfSyijgKtZqjxuy8/MEvWfWDLrE/rrH09KspeGZvbk6w
heesJytlPJ/3yegP3FNVJC1LYOfJUVIHrVfgj6ssfx78trcGySn3aZZqyTwllGHP
wFGUT9gy+k6RGoP0GBLWPbI+vpadD5jlxaLu/tO1h4AfZG2066RnMjs7II3p4HOs
0Tj/YwaMmNDybbpaIgE8bVnVjkarLIaBAxRs7zdrG+I2VGsWSEEESvJnxG9Z7BpK
q5x8zNXXcfb7ZD776HfTedFtiOIwqjxR5E/6mo8VP7m4sjqfcULRQYm9hDZrmQKv
cfeKRxTOlkoLJkQzsrbw8DOy6AfSuivc8V47BbM+4KGK8ktcwjFovPxvXJFXouWu
aBMhb+V8WSu5RdgXPuRRr/wugV/x8+xTsXpis00hjOVXoBp0wnIIt61pJ0A3OCp6
loNNWjfOApAPrmbRLM2FHhngZe5nrtpNKLz6I3mCkxfc9quNU+7XRB9y/5ZTwJiL
A9NSrRExB4+p0EpgffpikNLl8CBL9GBcEx1oBPc+0gybJadXI+I=
=Lr8N
-----END PGP SIGNATURE-----

--yRRfwbsvs08O+S4M--