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
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 |