> 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
