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

Поиск
Список
Период
Сортировка
От Joel Jacobson
Тема Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
Дата
Msg-id 149c402d-54c9-48dd-a730-2f5b958f2129@app.fastmail.com
обсуждение исходный текст
Ответ на Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue  (Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>)
Список pgsql-hackers
On Sat, Oct 25, 2025, at 15:08, Arseniy Mukhin wrote:
> I reimplemented the test in 0002 as an isolation test and added the
> commit message. PFA the new version.

I've rebased the patches so they can be applied on top of v12:
- v12-vacuum_notify_queue_cleanup-without-code-dup.txt
- v12-vacuum_notify_queue_cleanup-with-code-dup.txt

I also want to share a new idea that Heikki Linnakangas came up with
during PgConf25 in Riga.

The idea is basically to scan the notification queue from tail to head,
and update xids that precedes newFrozenXid, to either
FrozenTransactionId if committed, or InvalidTransactionId if not.

I've implemented this by adding a new extern function
AsyncNotifyFreezeXids to async.h, called from vac_update_datfrozenxid.

This way, we don't need to hold back the advancement of newFrozenXid in
vac_update_datfrozenxid.

Attempt of implementing Heikki's idea:
- async_notify_freeze_xids.txt

This idea has the benefit of never holding back newFrozenXid,
however, I see some problems with it:

- If there is a bug in the code, we could accidentally overwrite
  xid values we didn't intend to overwrite, and maybe we would never
  find out that we did.

- We wouldn't know for sure that we've understood the cause of
  this bug.

With v12-vacuum_notify_queue_cleanup, we instead have the downside of
possibly holding back newFrozenXid, but with the advantage of giving us
higher confidence in that we've correctly identified the cause of the
bug.

/Joel
Вложения

В списке pgsql-hackers по дате отправления: