Re: Xact end leaves CurrentMemoryContext = TopMemoryContext

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: David Rowley <dgrowleyml(at)gmail(dot)com>
Cc: pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Date: 2024-06-18 04:53:48
Message-ID: 3535687.1718686428@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

David Rowley <dgrowleyml(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2024-06-18 05:26:45 Re: Pgoutput not capturing the generated columns
Previous Message Dilip Kumar 2024-06-18 04:47:32 Re: Conflict Detection and Resolution