Re: Xact end leaves CurrentMemoryContext = TopMemoryContext

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

On Tue, 18 Jun 2024 at 08:37, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> 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?

Instead, could we just not delete TopTransactionContext in
AtCommit_Memory() and instead do MemoryContextReset() on it? Likewise
in AtCleanup_Memory().

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.

It might also be a very tiny amount more efficient to not delete the
context so we don't have to fetch a new context from the context
freelist in AtStart_Memory(). Certainly, it wouldn't add any
overhead. Adding a new special context would and so would the logic
to reset it every so often.

David

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dilip Kumar 2024-06-18 04:47:32 Re: Conflict Detection and Resolution
Previous Message Ashutosh Sharma 2024-06-18 04:14:54 Re: Addressing SECURITY DEFINER Function Vulnerabilities in PostgreSQL Extensions