Re: [BUG] temporary file usage report with extended protocol and unnamed portals

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