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