Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Guillaume Lelarge <guillaume.lelarge@dalibo.com>
Cc: Frédéric Yhuel <frederic.yhuel@dalibo.com>, Sami Imseih <samimseih@gmail.com>, 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>, Pierrick Chovelon <pierrick.chovelon@dalibo.com>
Date: 2025-09-26T11:33:02Z
Lists: pgsql-hackers
On Fri, Sep 26, 2025 at 09:28:15AM +0200, Guillaume Lelarge wrote: > 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. The question would be if we can come up with a fix solid enough to be able to detect the fact that we are dealing with one or more edge cases, one edge case being an unnamed portal dropped at the beginning of a bind from a different query, assuming that we don't change the protocol documented. What I'm afraid of is that this would be similar to the proposals in the original patch (not really clean at it used a direct point to the debug query string) or v13 (pstrdup of the debug string), which are both localized changes, and these seem unsafe to do because we'd expect the saved data to have the same durability as the portal it's related to. I'm not sure that there is a sane thing to do except dropping unnamed portals more aggressively, which may be OK still not backpatchable. -- Michael
Commits
-
Drop unnamed portal immediately after execution to completion
- 1fd981f05369 19 (unreleased) landed
-
Override log_error_verbosity to "default" in test 009_log_temp_files
- 02c171f63fca 19 (unreleased) landed
-
Add tests for logging of temporary file removal and statement
- 76bba033128a 19 (unreleased) landed