Re: [BUG] temporary file usage report with extended protocol and unnamed portals
От | Sami Imseih |
---|---|
Тема | Re: [BUG] temporary file usage report with extended protocol and unnamed portals |
Дата | |
Msg-id | CAA5RZ0s_oqiC_k3nu70asc32Me6aOjHQ4EAApy4tULFLZvk0vA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [BUG] temporary file usage report with extended protocol and unnamed portals (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: [BUG] temporary file usage report with extended protocol and unnamed portals
|
Список | pgsql-hackers |
> 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. v13 does not call pstrdup. It keeps a reference to debug_query_string, reassigns it to the Portal's query string during PortalDrop, then restores the original reference before return. Before PortalDrop exits, the temp file is closed and the message is emitted. I relied on [0] and debugging to check the safety of this approach. With that said, there could be edge cases where this may not be true. > 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. Yeah, I agree. This was in fact one of the ideas earlier. It is not clear to me why we should wait until the next bind to drop the last unnamed portal. [0] https://github.com/postgres/postgres/blob/master/src/backend/tcop/postgres.c#L1224-L1234 -- Sami
В списке pgsql-hackers по дате отправления: