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
-
Add test for temporary file removal and WITH HOLD cursor
- e7cde9dad285 19 (unreleased) landed
-
Revert "Drop unnamed portal immediately after execution to completion"
- 910690415b66 19 (unreleased) landed
-
Drop unnamed portal immediately after execution to completion
- 1fd981f05369 19 (unreleased) cited