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 | CAFY6G8f0JEF3HE4Q+ZZYjpPiFfRREzJ+r6zbJh2ZUFb2jhqm7g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue (Rishu Bagga <rishu.postgres@gmail.com>) |
Ответы |
Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
|
Список | pgsql-hackers |
On Wed Sep 3, 2025 at 8:51 PM -03, Rishu Bagga wrote: > On Wed, Sep 3, 2025 at 2:14 PM Matheus Alcantara > > <matheusssilv97@gmail.com> wrote: > > >> IIUC we don't store notifications of aborted transactions on the > >> queue. On PreCommit_Notify we add the notifications on the queue > >> and on Commit_Notify() we signal the backends. > >> > >> Or I'm missing something here? > > > My understanding is that something could go wrong in between > > PreCommit_Notify and AtCommit_Notify, which could cause the > > transaction to abort, and the notification might be in the queue at > > this point, even though the transaction aborted, hence the dependency > > on the commit log. > Ok, I agree that that this may happen but I don't see this as a common case to fix the issue based on this behaviour. I think that we check the transaction status also to skip notifications that were added on the queue by transactions that are not fully committed yet, and I see this scenario as a more common case but I could be wrong. -- Matheus Alcantara
В списке pgsql-hackers по дате отправления: