On 26/09/2025 08:45, Frédéric Yhuel wrote:
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.
Yeah, I don't see how it could help the user if PostgreSQL logs the
wrong query. At the very least, it should be written in the manual that
the user can't trust the STATEMENT line with temporary files logging.
But I would rather see it log the right query.
--
Guillaume Lelarge
Consultant
https://dalibo.com
