Re: Xact end leaves CurrentMemoryContext = TopMemoryContext

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Дата
Msg-id 3535687.1718686428@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Xact end leaves CurrentMemoryContext = TopMemoryContext  (David Rowley <dgrowleyml@gmail.com>)
Ответы Re: Xact end leaves CurrentMemoryContext = TopMemoryContext
Список 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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: Conflict Detection and Resolution
Следующее
От: Peter Smith
Дата:
Сообщение: Re: Pgoutput not capturing the generated columns