On 4/23/25 18:13, Sami Imseih wrote:
Also, another strange behavior of the way portal cleanup occurs is that
in extended-query-protocol and within a transaction, ExecutorEnd for the
last query is not actually called until the next command. This just seems
odd to me especially for extensions that rely on ExecutorEnd.
So, Can we do something like this? This drops the portal as soon as
execution completes ( the portal is fetched to completion ). This will
ensure that there is no delay in ExecutorEnd getting called and in the
case of log_temp_files, the message will be logged while debug_query_string
is still pointing to the correct query.
diff --git a/src/backend/tcop/postgres.c b/src/backend/tcop/postgres.c
index dc4c600922d..efe0151ca8f 100644
--- a/src/backend/tcop/postgres.c
+++ b/src/backend/tcop/postgres.c
@@ -2327,6 +2327,9 @@ exec_execute_message(const char *portal_name,
long max_rows)
/* Send appropriate CommandComplete to client */
EndCommand(&qc, dest, false);
+
+ if (!portal->portalPinned)
+ PortalDrop(portal, false);
}
else
{
I don't know if it is the correct solution, but it seems good to me
(FWIW), and I've tested it and it works well in all the following cases:
* Java program: extended protocol used for the two queries (the one that
use the temp file and the SELECT 1).
* Python program: the SELECT 1 is using the simple protocol.
* SQL PREPARE / EXECUTE
* Another version of the Java program using the
setFetchSize() method (and named portals).
