Mime-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset=UTF-8
Date: Tue, 21 Oct 2025 20:16:49 -0300
Message-Id: <DDODT698DICW.1OMV62ZFTGAUG@gmail.com>
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: "Masahiko Sawada" <sawada.mshk@gmail.com>, "Matheus Alcantara"
 <matheusssilv97@gmail.com>
Cc: =?utf-8?q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>, "Joel Jacobson"
 <joel@compiler.org>, "Arseniy Mukhin" <arseniy.mukhin.dev@gmail.com>,
 "Rishu Bagga" <rishu.postgres@gmail.com>, "Yura Sokolov"
 <y.sokolov@postgrespro.ru>, "Daniil Davydov" <3danissimo@gmail.com>,
 "Alexandra Wang" <alexandra.wang.oss@gmail.com>, "pgsql-hackers"
 <pgsql-hackers@postgresql.org>, "Tom Lane" <tgl@sss.pgh.pa.us>
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async
 queue
References: <DDN5OD2RQFF4.CW8X8CMVQAJC@gmail.com>
 <202510201414.56f2msqusjla@alvherre.pgsql>
 <DDNCV8U74QPS.KBHN82IW5S4X@gmail.com>
 <CAD21AoA8sjvRgL6h-wC-3x7VXu7ZjB3K1vLGgND-SbD-NPdQDg@mail.gmail.com>
In-Reply-To: 
 <CAD21AoA8sjvRgL6h-wC-3x7VXu7ZjB3K1vLGgND-SbD-NPdQDg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/DDODT698DICW.1OMV62ZFTGAUG%40gmail.com>
Precedence: bulk

On 21/10/25 18:42, Masahiko Sawada wrote:
> On Mon, Oct 20, 2025 at 11:19=E2=80=AFAM Matheus Alcantara
> <matheusssilv97@gmail.com> wrote:
>>
>> On Mon Oct 20, 2025 at 11:18 AM -03, =C3=81lvaro Herrera wrote:
>>> On 2025-Oct-20, Matheus Alcantara wrote:
>>>
>>>> This is similar to what was already proposed at [1]. This approach was
>>>> abandoned because a notification on the queue may block datfrozenxid
>>>> advance and clog truncation which can cause other issues for the users=
 [2].
>>>
>>> Well, I think that this is the right solution for backpatching, and tha=
t
>>> you were wrong to abandon it.  You can continue to design a better
>>> mechanism for the master branch, but in old branches we cannot really d=
o
>>> all those things you're proposing to do.
>>>
>> I actually would prefer this approach TBH, but since this can cause
>> other issues like transaction wraparound due to not consumed
>> notifications we would need other mechanisms to prevent that and I'm not
>> sure if users should expect this kind of behavior changes on minor
>> version updates?
>=20
> True, unconsumed notifications could cause transaction wraparound by
> preventing datfrozenxid from advancing. However, this risk only
> applies when users have long-term unconsumed notifications, which is
> uncommon. That said, we should note that, as I mentioned
> previously[1], a process can accumulate unconsumed notifications
> simply by being in idle-in-transaction state, even without
> backend_xmin and backend_xid, which prevents datfrozenxid from
> advancing. While this might not be problematic in practice if it's
> rare, I find it concerning that we have no way to check the age of
> unconsumed notifications.
>
Ok, I think that I was too conservative when thinking about the
transaction wraparound issue that it could happen. I agree that this
seems a uncommon scenario.

>> I think that to go with this solution we would need some way to drop too
>> old notifications from the queue to advance the datfrozenxid, so I
>> imagine that we would need some GUC to make this configurable and we can
>> configure a default value of course but some use cases may not be the
>> best configuration, this is something that users should expected to deal
>> on minor version updates?
>=20
> I think adding a new GUC would be overkill for this fix. As for
> dropping old notifications from the queue, we probably don't need to
> make it configurable - we could simply drop notifications whose commit
> status is no longer available (instead of raising an error).
>
IIUC this is about not making the vacuum freeze considering the oldest
xid on the queue but just remove notifications whose transaction status
is no longer available right? Since currently when the error happens we
already can't process the notifications it seems a reasonable way to go
IMO.

>> Going with the "self contained" idea sound more easier to backpatch
>> actually, so this is the main reason that I abandoned this other
>> approach. Could you please point what make the v8 version not visible
>> for bachpatching?
>=20
> Regarding the v8 patch, it introduces a fundamentally new way of
> managing notification entries (adding entries with 'committed' state
> and marking them 'aborted' in abort paths). This affects all use
> cases, not just those involving very old unconsumed notifications, and
> could introduce more serious bugs like PANIC or SEGV. For
> backpatching, I prefer targeting just the problematic behavior while
> leaving unrelated parts unchanged. Though =C3=81lvaro might have a
> different perspective on this.
>
Thanks very much for this explanation and for what you've previously
wrote on [1]. It's clear to me now that the v8 architecture is not a
good way to go.

[1] https://www.postgresql.org/message-id/CAD21AoCFZxXCBy%2B5DoarfG9LC9VdNw=
WRDpDHE5sdTh5Ym0EcqQ%40mail.gmail.com

--=20
Matheus Alcantara