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: "Masahiko Sawada" <sawada.mshk@gmail.com>
Cc: "Daniil Davydov" <3danissimo@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, "Alexandra Wang" <alexandra.wang.oss@gmail.com>, "PostgreSQL Hackers" <pgsql-hackers@postgresql.org>
Date: 2025-08-21T23:14:47Z
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 Thu Aug 21, 2025 at 7:25 PM -03, Masahiko Sawada wrote:
> What about backend processes that don't have any xid or xmin (i.e.,
> are read-only query and in idle-in-transaction)?
>
> IIUC we process the notification entries at the beginning of the
> server loop (see L4608 in postgres.c) and when reading a command (via
> ProcessClientReadInterrupt()), but it seems to me that if a process is
> in idle-in-transaction state it doesn't process the entries unless the
> transaction is committed. I've reproduced the missing clog entry error
> even if we have a notification on the queue with a valid listener,
> with the following steps:
>
Ok, now we can reproduce this, thank you! So I think that we need a way
to teach the VACUUM FREEZE about old xid's on async queue.

I'll work on this considering the initial Daniil comments at [1]

[1] https://www.postgresql.org/message-id/CAJDiXgg1ArRB1-6wLtXfVVnQ38P9Y%2BCDfEc9M2TXiOf_4kfBMg%40mail.gmail.com

--
Matheus Alcantara