Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-06-18T04:34:43Z
Lists: 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
Commits
-
Split vacuumdb to create vacuuming.c/h
- c4067383cb2c 19 (unreleased) cited
-
Preserve CurrentMemoryContext across notify and sinval interrupts.
- 8565fb6fbb69 12.20 landed
- 5f86cd70d801 13.16 landed
- 54a7b21b3a9d 16.4 landed
- 4df767cf906d 15.8 landed
- 31f8d620b287 17.0 landed
- 1608902fc3a7 14.13 landed
-
Preserve CurrentMemoryContext across Start/CommitTransactionCommand.
- 1afe31f03cd2 18.0 landed