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).
