Horton

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

Álvaro Herrera <alvherre@kurilemu.de>

View thread
From: Álvaro Herrera <alvherre@kurilemu.de>
To: 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-20T14:18: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 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.

-- 
Álvaro Herrera         PostgreSQL Developer  —  https://www.EnterpriseDB.com/
"Cómo ponemos nuestros dedos en la arcilla del otro. Eso es la amistad; jugar
al alfarero y ver qué formas se pueden sacar del otro" (C. Halloway en
La Feria de las Tinieblas, R. Bradbury)