On Tue, 18 Jun 2024 at 08:37, Tom Lane <t...@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
