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
