Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue - Mailing list pgsql-hackers

From Matheus Alcantara
Subject Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Date
Msg-id CAFY6G8e8WfUkH6iij4q3banqw_v0j2aSB7_bnoTtgMthTCSXOw@mail.gmail.com
Whole thread Raw
In response to Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
On Tue Aug 19, 2025 at 2:40 PM -03, Masahiko Sawada wrote:
> However, I have a more fundamental concern regarding the LISTEN/NOTIFY
> implementation. Since vacuum doesn't consider the XIDs of notification
> entries, there might be a critical issue with the truncation of clog
> entries that LISTEN/NOTIFY still requires. As I understand it,
> notification queue entries aren't ordered by XID, and it's possible
> for a notification with an older XID to be positioned at the queue's
> head. If vacuum freeze then truncates the corresponding clogs,
> listeners attempting to retrieve this notification would fail to
> obtain the transaction status. To address this, we likely need to
> either implement Álvaro's suggestion[1] to make vacuum aware of the
> oldest XID in the notification queue, or develop a mechanism to
> remove/freeze XIDs of the notification entries.
>
Thanks for the comments! Please see my reply at [1] that I mention that
I don't think that is too easy to have this specific scenario of a busy
backend loose dropped notifications.

[1] https://www.postgresql.org/message-id/DC7KGTXW3QSG.OZA24HONT78J%40gmail.com

--
Matheus Alcantara



pgsql-hackers by date:

Previous
From: "Matheus Alcantara"
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Next
From: Michael Paquier
Date:
Subject: Re: Add GUC to enable libxml2's XML_PARSE_HUGE