Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: David Rowley <dgrowleyml@gmail.com>
Cc: pgsql-hackers@lists.postgresql.org
Date: 2024-06-18T04:53:48Z
Lists: pgsql-hackers
David Rowley <dgrowleyml@gmail.com> writes: > Instead, could we just not delete TopTransactionContext in > AtCommit_Memory() and instead do MemoryContextReset() on it? Likewise > in AtCleanup_Memory(). Hmm, that's a nice idea. Maybe reset again in AtStart_Memory, although that seems optional. My first reaction was "what about memory context callbacks attached to TopTransactionContext?" ... but those are defined to be fired on either reset or delete, so semantically this seems like it creates no issues. And you're right that not constantly deleting and recreating that context should save some microscopic amount. > 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. My point is exactly that I don't think that we can expect that, or at least that the cost of guaranteeing it will vastly outweigh any possible benefit. (So I wasn't excited about Andres' suggestion. But this one seems promising.) I'll poke at this tomorrow, unless you're hot to try it right now. regards, tom lane
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