Horton

Xact end leaves CurrentMemoryContext = TopMemoryContext

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: pgsql-hackers@lists.postgresql.org
Date: 2024-06-17T20:37:05Z
Lists: pgsql-hackers 
AtCommit_Memory and friends have done $SUBJECT for at least a couple
of decades, but in the wake of analyzing bug #18512 [1], I'm feeling
like that's a really bad idea.  There is too much code running
around the system that assumes that it's fine to leak stuff in
CurrentMemoryContext.  If we execute any such thing between
AtCommit_Memory and the next AtStart_Memory, presto: we have a
session-lifespan memory leak.  I'm almost feeling that we should
have a policy that CurrentMemoryContext should never point at
TopMemoryContext.

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?

			regards, tom lane

[1] https://www.postgresql.org/message-id/18512-6e89f654d7da884d%40postgresql.org

Commits

  1. Split vacuumdb to create vacuuming.c/h

  2. Preserve CurrentMemoryContext across notify and sinval interrupts.

  3. Preserve CurrentMemoryContext across Start/CommitTransactionCommand.