Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Date
Msg-id aHbk8A4bSBIYtHIl@paquier.xyz
Whole thread Raw
In response to Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
List pgsql-bugs
On Tue, Jul 15, 2025 at 12:05:34PM -0400, Tom Lane wrote:
> In short, Alvaro's patch definitely seems like the right one,
> modulo quibbles about rewriting the comment.

+++ b/src/backend/tcop/pquery.c
@@ -1350,24 +1350,14 @@ PortalRunMulti(Portal portal,
[...]
-    if (qc && qc->commandTag == CMDTAG_UNKNOWN)
-    {
-        if (portal->qc.commandTag != CMDTAG_UNKNOWN)
-            CopyQueryCompletion(qc, &portal->qc);
-        /* If the caller supplied a qc, we should have set it by now. */
-        Assert(qc->commandTag != CMDTAG_UNKNOWN);
-    }
+    if (qc &&
+        qc->commandTag == CMDTAG_UNKNOWN &&
+        portal->qc.commandTag != CMDTAG_UNKNOWN)
+        CopyQueryCompletion(qc, &portal->qc);

Indeed this change looks OK.

> Perhaps we should
> add something about the possibility that an outer Portal level
> can supply a default command tag if we lack one now?

You mean as an extra assertion?  I am not sure that this is strongly
necessary but why not.
--
Michael

Attachment

pgsql-bugs by date:

Previous
From: Erik Dobák
Date:
Subject: Re: BUG #18985: fast shutdown does not close connections from qlik data gateway data movement aka. replicate
Next
From: Tom Lane
Date:
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti