Re: pgsql: Drop unnamed portal immediately after execution to completion

Tom Lane <tgl@sss.pgh.pa.us>

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>
Date: 2025-11-10T21:28:02Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 5, 2025 at 12:43 AM 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



Commits

  1. Add test for temporary file removal and WITH HOLD cursor

  2. Revert "Drop unnamed portal immediately after execution to completion"

  3. Drop unnamed portal immediately after execution to completion