Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ubiA1-004HgN-LI for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jul 2025 16:05:41 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1ubi9z-003FUH-OH for pgsql-bugs@arkaria.postgresql.org; Tue, 15 Jul 2025 16:05:40 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1ubi9z-003FTt-Fs for pgsql-bugs@lists.postgresql.org; Tue, 15 Jul 2025 16:05:40 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1ubi9x-007QiM-1z for pgsql-bugs@lists.postgresql.org; Tue, 15 Jul 2025 16:05:38 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 56FG5Y14923532; Tue, 15 Jul 2025 12:05:34 -0400 From: Tom Lane To: =?UTF-8?B?w4PCgWx2YXJvIEhlcnJlcmE=?= cc: Michael Paquier , 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: <799185.1752535067@sss.pgh.pa.us> References: <18984-0f4778a6599ac3ae@postgresql.org> <715434.1752521761@sss.pgh.pa.us> <799185.1752535067@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Mon, 14 Jul 2025 19:17:47 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <923530.1752595534.1@sss.pgh.pa.us> Date: Tue, 15 Jul 2025 12:05:34 -0400 Message-ID: <923531.1752595534@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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