Horton

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

Frédéric Yhuel <frederic.yhuel@dalibo.com>

View thread View on postgr.es
From: Frédéric Yhuel <frederic.yhuel@dalibo.com>
To: Michael Paquier <michael@paquier.xyz>, Sami Imseih <samimseih@gmail.com>
Cc: Mircea Cadariu <cadariu.mircea@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Benoit Lobréau <benoit.lobreau@dalibo.com>, Guillaume Lelarge <guillaume.lelarge@dalibo.com>, Pierrick Chovelon <pierrick.chovelon@dalibo.com>
Date: 2025-09-26T06:45:25Z
Lists: pgsql-hackers 

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.

Commits

  1. Drop unnamed portal immediately after execution to completion

  2. Override log_error_verbosity to "default" in test 009_log_temp_files

  3. Add tests for logging of temporary file removal and statement