Re: [BUG] temporary file usage report with extended protocol and unnamed portals
От | Michael Paquier |
---|---|
Тема | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Дата | |
Msg-id | aNZ57gwR20hCBIq7@paquier.xyz обсуждение исходный текст |
Ответ на | Re: [BUG] temporary file usage report with extended protocol and unnamed portals (Guillaume Lelarge <guillaume.lelarge@dalibo.com>) |
Ответы |
Re: [BUG] temporary file usage report with extended protocol and unnamed portals
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: