> 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
