Hi,
This change seems to have introduced an issue where a deleted context
can be restored. This happens when a replication command exports a
snapshot since the transaction used is aborted at the start of the
next command. This leads to a memory context allocated with itself as
a parent and child,
Andres Freund writes:
> I wonder if there's an argument the "persistent" TopTransactionContext should
> live under a different name outside of transactions, to avoid references to it
> working in a context where it's not valid? It's probably not worth it, but
> not sure.
Hm. We could stash the
Hi,
On 2024-06-18 15:28:03 -0400, Tom Lane wrote:
> After awhile I had an epiphany: what we should do is make
> CommitTransactionCommand restore the memory context that was active
> before StartTransactionCommand. That's what we want in every place
> that was cognizant of this issue, and it seems
David Rowley writes:
> On Tue, 18 Jun 2024 at 16:53, Tom Lane wrote:
>> I'll poke at this tomorrow, unless you're hot to try it right now.
> Please go ahead. I was just in suggestion mode here.
So I tried that, and while it kind of worked, certain parts of the
system (notably logical replicatio
On Tue, 18 Jun 2024 at 16:53, Tom Lane wrote:
> I'll poke at this tomorrow, unless you're hot to try it right now.
Please go ahead. I was just in suggestion mode here.
David
David Rowley 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 "w
On Tue, 18 Jun 2024 at 08:37, Tom Lane 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
Hi,
On 2024-06-17 16:37:05 -0400, Tom Lane 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 exist
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 execut
