| From: | Frédéric Yhuel <frederic(dot)yhuel(at)dalibo(dot)com> |
|---|---|
| To: | Michael Paquier <michael(at)paquier(dot)xyz>, Sami Imseih <samimseih(at)gmail(dot)com> |
| Cc: | Mircea Cadariu <cadariu(dot)mircea(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Benoit Lobréau <benoit(dot)lobreau(at)dalibo(dot)com>, Guillaume Lelarge <guillaume(dot)lelarge(at)dalibo(dot)com>, Pierrick Chovelon <pierrick(dot)chovelon(at)dalibo(dot)com> |
| Subject: | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
| Date: | 2025-09-26 06:45:25 |
| Message-ID: | f805707f-889f-4076-a3c8-d24e1ea35996@dalibo.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Ashutosh Sharma | 2025-09-26 07:00:19 | Re: issue with synchronized_standby_slots |
| Previous Message | Chao Li | 2025-09-26 06:34:58 | Re: Add memory_limit_hits to pg_stat_replication_slots |