Re: Memory context can be its own parent and child in replication command

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Anthonin Bonnefoy <anthonin(dot)bonnefoy(at)datadoghq(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Memory context can be its own parent and child in replication command
Date: 2025-03-11 01:13:17
Message-ID: 1343524.1741655597@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Michael Paquier <michael(at)paquier(dot)xyz> writes:
> On Mon, Mar 10, 2025 at 09:07:59AM +0100, Anthonin Bonnefoy wrote:
>> The issue seems to have been introduced by 2129d184a206c when
>> transactionState->priorContext was added and is only present in HEAD.

> It seems to me that you mean 1afe31f03cd2, no?

I dunno about this patch: it seems to me it's doing things exactly
backwards, namely trying to restore the CurrentMemoryContext after
a transaction abort to what it was just beforehand. With only
a slightly different set of suppositions, this is introducing
use of a deleted context rather than removing it.

I'm inclined to suspect that the real problem is somebody installed
the wrong context as current just before the transaction was started.
I don't have the energy to look closer right now, though.

Independently of where the actual bug is there, it seems not
nice that it's so easy to bollix the memory context data
structures. I wonder if we can make that more detectable
at reasonable cost.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Rowley 2025-03-11 01:16:07 Re: Printing window function OVER clauses in EXPLAIN
Previous Message David G. Johnston 2025-03-11 00:31:41 Re: Adding a '--clean-publisher-objects' option to 'pg_createsubscriber' utility.