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.
