Re: [BUG] temporary file usage report with extended protocol and unnamed portals - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [BUG] temporary file usage report with extended protocol and unnamed portals
Date
Msg-id aNZ57gwR20hCBIq7@paquier.xyz
Whole thread Raw
In response to Re: [BUG] temporary file usage report with extended protocol and unnamed portals  (Guillaume Lelarge <guillaume.lelarge@dalibo.com>)
List 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

Attachment

pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Shlok Kyal
Date:
Subject: Re: How can end users know the cause of LR slot sync delays?