Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
От | Matheus Alcantara |
---|---|
Тема | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
Дата | |
Msg-id | CAFY6G8e8WfUkH6iij4q3banqw_v0j2aSB7_bnoTtgMthTCSXOw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue (Masahiko Sawada <sawada.mshk@gmail.com>) |
Список | 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 по дате отправления: