From: Michael Paquier <michael@paquier.xyz>
To: Mircea Cadariu <cadariu.mircea@gmail.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: pgsql: Drop unnamed portal immediately after execution to completion
Date: Thu, 13 Nov 2025 15:27:23 +0900
Message-ID: <aRV6D3vxMQTQ7CxG@paquier.xyz> (raw)
In-Reply-To: <00d71a54-2118-4b18-87e8-33f4a99dc624@gmail.com>
References: <E1vGWIt-0056al-2N@gemulon.postgresql.org>
<CA+TgmoYFJyJNQw3RT7veO3M2BWRE9Aw4hprC5rOcawHZti-f8g@mail.gmail.com>
<1982325.1762810082@sss.pgh.pa.us>
<aRJ1zn0z-Bn0qc2H@paquier.xyz>
<CA+TgmoYR2OP8C+MHC8VCA80-r=Q09aF-_=juvBLvUKS09d__Mw@mail.gmail.com>
<00d71a54-2118-4b18-87e8-33f4a99dc624@gmail.com>
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
Attachments:portal-cleanup.patch (text/x-diff, 1.1K) downloaddiff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.cindex 2bd89102686e..8d3739298afe 100644--- a/src/backend/tcop/postgres.c+++ b/src/backend/tcop/postgres.c@@ -38,6 +38,7 @@
#include "commands/async.h"
#include "commands/event_trigger.h"
#include "commands/explain_state.h"
+#include "commands/portalcmds.h"
#include "commands/prepare.h"
#include "common/pg_prng.h"
#include "jit/jit.h"
@@ -2330,13 +2331,14 @@ exec_execute_message(const char *portal_name, long max_rows)
/*
* We completed fetching from an unnamed portal. There is no need
- * for it beyond this point, so drop it now rather than wait for+ * for it beyond this point, so clean it now rather than wait for
* the next Bind message to do this cleanup. This ensures that
* the correct statement is logged when cleaning up temporary file
- * usage.+ * usage with the executor shutdown.
*/
- if (portal->name[0] == '\0')- PortalDrop(portal, false);+ if (portal->name[0] == '\0' &&+ portal->cleanup)+ PortalCleanup(portal);
}
/* Send appropriate CommandComplete to client */
signature.asc (application/pgp-signature, 832B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-committers@postgresql.org
Cc: michael@paquier.xyz, cadariu.mircea@gmail.com, robertmhaas@gmail.com, tgl@sss.pgh.pa.us, frederic.yhuel@dalibo.com, pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Drop unnamed portal immediately after execution to completion
In-Reply-To: <aRV6D3vxMQTQ7CxG@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox