On Sat, Sep 27, 2025 at 12:44:23PM -0500, Sami Imseih wrote:
>> 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
I cannot say for sure, but my bet goes to efficiency. Dropping an
unnamed portal at the next bind is an artifact from 2003, fe19e56c572f
if my grep gets it right. log_temp_files is a bit older than that,
with be8a4318815.
FWIW, I don't really object to being more aggressive with the unnamed
portal drop. What I am going to object to is hacks that attempt to
work around this protocol artifact by relying on things that may have
a different lifetime than the portal dropped. I think that the
correct step would be to get some coverage in, reversing the order of
the patches. Then, let's deal with how the reports are changed in the
tests by making the portal drop more aggressive in one location or
another, even if it costs one extra hash table lookup. We cannot
backpatch that, still as your TAP script is proving the coverage
is easier with all these new psql meta-commands able to do extended
protocol manipulations.
--
Michael
