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

On 9/26/25 03:20, Michael Paquier wrote:
> Thinking about this problem in a twisted way, could there be an
> argument in favor of the existing logic as it is?  It is true that the
> cleanup happens when the next bind query happens.  So, in fact, one
> could also say that it makes sense to reflect when a temp file is
> cleaned up and what's the query being processed that does the cleanup.
> In this case, it is not the query that created the temp file, but the
> one that's been processed, and the portal drop is documented in
> protocol.sgml as being part of the follow-up BIND.  (I did use the
> term "twisted" here.)

Well, that is indeed a rather twisted approach ;-)

How are we going to explain this to the user?

Is it really acceptable to have this in the log?

[...] LOG:  temporary file: path "base/pgsql_tmp/pgsql_tmp525566.0", 
size 2416640
[...] STATEMENT:  SELECT 1

If we're unable to provide a proper fix, we should probably remove 
completely the "STATEMENT" log line. We can use pg_stat_statements to 
find the amount of temporary file written by a given query.