Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
От | David Rowley |
---|---|
Тема | Re: Xact end leaves CurrentMemoryContext = TopMemoryContext |
Дата | |
Msg-id | CAApHDvoS0WxT0O2=4xHoYEQjondJNLt-AmDnB8AoFb4to+hxgg@mail.gmail.com обсуждение исходный текст |
Ответ на | Xact end leaves CurrentMemoryContext = TopMemoryContext (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: