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 CAFY6G8f0JEF3HE4Q+ZZYjpPiFfRREzJ+r6zbJh2ZUFb2jhqm7g@mail.gmail.com
Whole thread Raw
In response to Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue  (Rishu Bagga <rishu.postgres@gmail.com>)
Responses Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue
List 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 by date:

Previous
From: Oreo Yang
Date:
Subject: 回复: Differential Code Coverage report for Postgres
Next
From: "Matheus Alcantara"
Date:
Subject: Re: LISTEN/NOTIFY bug: VACUUM sets frozenxid past a xid in async queue