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

On Mon, Nov 10, 2025 at 04:28:02PM -0500, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> 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.

All the other solutions mentioned mean to work around the issue of the
unnamed portal still being present by maintaining the query string it
in a different context across multiple messages.  And I doubt that
anybody would be thrilled by that.

If you think that we should continue to live with the protocol for
unnamed portals as-is and continue to live with the existing behavior,
meaning a revert of 1fd981f05369, that would not be the end of the
world here: we'd still have some tests that track the
past-and-currently-released behavior.

Even if strange, it works with the timing where the unnamed protocol
is dropped.  Perhaps somebody would be able to come up with a approach
better than a more aggressive portal drop once completed, but I don't
quite see how much can be done as long as we manipulate the unnamed
portals this way (aka drop then with a follow-up bind, and expect the
logging to show the correct statements attached to a previous
message that we have no knowledge about).  The original statement
logging did not really consider all these fancier cases with the
extended query protocol.
--
Michael