Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Ã?lvaro Herrera <alvherre(at)kurilemu(dot)de>, exclusion(at)gmail(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Date: 2025-07-15 23:32:00
Message-ID: aHbk8A4bSBIYtHIl@paquier.xyz
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2025-07-15 23:40:19 Re: BUG #18984: Empty prepared statement from psql \parse triggers assert in PortalRunMulti
Previous Message Erik Dobák 2025-07-15 18:38:46 Re: BUG #18985: fast shutdown does not close connections from qlik data gateway data movement aka. replicate