From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
cc: Michael Paquier <michael@paquier.xyz>,
        PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Drop unnamed portal immediately after execution to
 completion
In-reply-to: 
 <CA+TgmoYFJyJNQw3RT7veO3M2BWRE9Aw4hprC5rOcawHZti-f8g@mail.gmail.com>
References: <E1vGWIt-0056al-2N@gemulon.postgresql.org>
 <CA+TgmoYFJyJNQw3RT7veO3M2BWRE9Aw4hprC5rOcawHZti-f8g@mail.gmail.com>
Comments: In-reply-to Robert Haas <robertmhaas@gmail.com>
	message dated "Mon, 10 Nov 2025 16:13:24 -0500"
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-ID: <1982322.1762810082.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 10 Nov 2025 16:28:02 -0500
Message-ID: <1982325.1762810082@sss.pgh.pa.us>
Archived-At: 
 <https://www.postgresql.org/message-id/1982325.1762810082%40sss.pgh.pa.us>
Precedence: bulk

Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 5, 2025 at 12:43=E2=80=AFAM Michael Paquier <michael@paquier=
.xyz> wrote:
>> Drop unnamed portal immediately after execution to completion

> This patch doesn't look well-considered to me. One problem is that
> it's a wire protocol change to fix a minor logging anomaly, which
> seems disproportionate. Another problem is that the new portal-drop
> behavior is conditional on whether XACT_FLAGS_NEEDIMMEDIATECOMMIT gets
> set, which seems unprincipled. In addition to those points, I am not
> entirely certain that the "here is no need for it beyond this point"
> comment is correct. I mean, I think it will normally be true, but what
> if the client wants to send a Describe message after-the-fact, or an
> additional Execute message that will presumably return zero rows?

Yeah, the whole idea of changing the wire-level behavior to fix this
has been making me itch: I don't believe for a moment that it won't
cause compatibility problems.  I do not have a better proposal for
fixing the problem though.

			regards, tom lane