Horton

Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue

Matheus Alcantara <matheusssilv97@gmail.com>

View thread
From: "Matheus Alcantara" <matheusssilv97@gmail.com>
To: Álvaro Herrera <alvherre@kurilemu.de>, "Matheus Alcantara" <matheusssilv97@gmail.com>
Cc: "Joel Jacobson" <joel@compiler.org>, "Arseniy Mukhin" <arseniy.mukhin.dev@gmail.com>, "Masahiko Sawada" <sawada.mshk@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>
Date: 2025-10-20T18:19:50Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clear 'xid' in dummy async notify entries written to fill up pages

  2. Fix remaining race condition with CLOG truncation and LISTEN/NOTIFY

  3. Fix bug where we truncated CLOG that was still needed by LISTEN/NOTIFY

  4. Escalate ERRORs during async notify processing to FATAL

  5. Limit the size of TID lists during parallel GIN build

On Mon Oct 20, 2025 at 11:18 AM -03, Álvaro 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 that
> 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 do
> 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? 

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?

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?

Thanks for the comments!

--
Matheus Alcantara