On Tue, 18 Jun 2024 at 08:37, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> As to what to do about it: I'm imagining that instead of resetting
> CurrentMemoryContext to TopMemoryContext, we set it to some special
> context that we expect we can reset every so often, like at the start
> of the next transaction. The existing TransactionAbortContext is
> a very similar thing, and maybe could be repurposed/shared with this
> usage.
>
> Thoughts?
Instead, could we just not delete TopTransactionContext in
AtCommit_Memory() and instead do MemoryContextReset() on it? Likewise
in AtCleanup_Memory().
If we got to a stage where we didn't expect anything to allocate into
that context outside of a transaction, we could check if the context
is still reset in AtStart_Memory() and do something like raise a
WARNING on debug builds (or Assert()) to alert us that some code that
broke our expectations.
It might also be a very tiny amount more efficient to not delete the
context so we don't have to fetch a new context from the context
freelist in AtStart_Memory(). Certainly, it wouldn't add any
overhead. Adding a new special context would and so would the logic
to reset it every so often.
David
