Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
| От | Álvaro Herrera |
|---|---|
| Тема | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue |
| Дата | |
| Msg-id | 202511041624.uthdnt3tzhm2@alvherre.pgsql обсуждение исходный текст |
| Ответ на | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue (Heikki Linnakangas <hlinnaka@iki.fi>) |
| Список | pgsql-hackers |
On 2025-Nov-04, Heikki Linnakangas wrote: > From 7c342e6efffc8d59c2e7658f6f2f3b138d02e0bb Mon Sep 17 00:00:00 2001 > From: Heikki Linnakangas <heikki.linnakangas@iki.fi> > Date: Tue, 4 Nov 2025 13:22:08 +0200 > Subject: [PATCH v2 1/2] Fix bug where we truncated CLOG that was still needed > by LISTEN/NOTIFY > The async notification queue contains the XID of the sender, and when > processing notifications we call TransactionIdDidCommit() on the > XID. But we had no safeguards to prevent the CLOG segments containing > those XIDs from being truncated away. As a result, if a backend didn't > for some reason process its notifications for a long time, or when a > new backend issued LISTEN, you could get an error like: > > test=# listen c21; > ERROR: 58P01: could not access status of transaction 14279685 > DETAIL: Could not open file "pg_xact/000D": No such file or directory. > LOCATION: SlruReportIOError, slru.c:1087 > > Note: This commit is not a full fix. [...] The commit message doesn't say just _what_ does the patch do to fix the bug though. Looking through the code, I think you're setting XIDs in the async queue to frozenXid, but I think the commit message should explain that. Thanks for spending time on this. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "La fuerza no está en los medios físicos sino que reside en una voluntad indomable" (Gandhi)
В списке pgsql-hackers по дате отправления: