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

On Wed, Nov 12, 2025 at 11:14:26AM +0000, Mircea Cadariu wrote:
> I understand the point that’s been raised. Would it be an option to indeed
> revert the portal drop in postgres.c, but then append the right query in the
> "temporary file: ..." log line instead? This would work at least for me.

This is new, attaching the information to a Vfd in fd.c.  Not sure
that adding this information to this structure is a good concept.
This layer of the code has no idea of query strings currently, so that
feels a bit like a layer violation.

Thinking a bit outside the box..  I was wondering about a plan D (plan
A is what's on HEAD, plan B is copying around the query string, plan C
this Vfd approach) where we shut down the executor when we have
finished the execution of an unnamed portal, with something like the
attached based on a more aggressive PortalCleanup().  However, that
would not fly far if the client decides to send an extra execute
message post-portal-completion where we'd still want the executor to
be around, even if there are no rows to process.  We presumably do not
need the temp files anymore at this stage, but I don't really like the
fact that we'd need to somehow take a shortcut if we want only to
clean up the temp files.

Perhaps the best answer for now is to revert and continue the
discussion for this cycle as there seem to be little love for the
current HEAD's solution with the protocol change.

If folks have more ideas or input, please feel free.
--
Michael