From: Tom Lane <tgl@sss.pgh.pa.us>
To: Ãlvaro Herrera <alvherre@kurilemu.de>
Cc: Michael Paquier <michael@paquier.xyz>
Cc: exclusion@gmail.com
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Date: Tue, 15 Jul 2025 12:05:34 -0400
Message-ID: <923531.1752595534@sss.pgh.pa.us> (raw)
In-Reply-To: <799185.1752535067@sss.pgh.pa.us>
References: <18984-0f4778a6599ac3ae@postgresql.org>
<715434.1752521761@sss.pgh.pa.us>
<799185.1752535067@sss.pgh.pa.us>
I wrote:
> BTW, with Asserts disabled it works fine:
> ...
> (I did not look into how come that works... the correct
> command tag must be getting filled in later, but where?)
I traced through this, and the answer is that there are two levels
of Portal, an outer one that holds the EXECUTE command (and has
portal->qc.commandTag = CMDTAG_EXECUTE) and an inner one that runs
the prepared statement's list (and has portal->qc.commandTag =
CMDTAG_UNKNOWN, because that list is empty). But ExecuteQuery
passes down the outer "qc" parameter to the inner recursion level.
So without the Assert, the inner invocation of PortalRunMulti leaves
qc->commandTag = CMDTAG_UNKNOWN, and then the very same stanza
of PortalRunMulti replaces that with CMDTAG_EXECUTE in the outer
recursion level.
So it's just wrong for PortalRunMulti to assert that the
computation of qc->commandTag is necessarily complete.
If we wanted to replace that, it might be appropriate to have an
assertion at the top level (exec_simple_query) but I'm not very sure
what that would buy us. It'll be apparent enough what happened from
the reported "???" command tag, and the top-level assertion would
contribute exactly nada to identifying where we'd missed setting it.
In short, Alvaro's patch definitely seems like the right one,
modulo quibbles about rewriting the comment. Perhaps we should
add something about the possibility that an outer Portal level
can supply a default command tag if we lack one now?
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, alvherre@kurilemu.de, michael@paquier.xyz, exclusion@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
In-Reply-To: <923531.1752595534@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox