Horton

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

Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>

View thread
From: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
To: Heikki Linnakangas <hlinnaka@iki.fi>
Cc: Matheus Alcantara <matheusssilv97@gmail.com>, Joel Jacobson <joel@compiler.org>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-05T18:17:19Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Clear 'xid' in dummy async notify entries written to fill up pages

  2. Fix remaining race condition with CLOG truncation and LISTEN/NOTIFY

  3. Fix bug where we truncated CLOG that was still needed by LISTEN/NOTIFY

  4. Escalate ERRORs during async notify processing to FATAL

  5. Limit the size of TID lists during parallel GIN build

On Wed, Nov 5, 2025 at 12:21 PM Heikki Linnakangas <hlinnaka@iki.fi> wrote:
>
> On 04/11/2025 16:40, Arseniy Mukhin wrote:
> > It seems that 0002 handles errors during NotifyMyFrontEnd a little differently.
> >
> > With master, in case of a failure during NotifyMyFrontEnd, the
> > listener's position in PG_FINALLY is set to the beginning of the next
> > notification, since we advance the "current" position only if the
> > previous notification was successfully sent.
> >
> > With 0002, we advance the "current" position while copying
> > notifications to the local buffer, and begin sending them after the
> > position has already been advanced for all copied notifications. So in
> > case of a failure, the listener's position in PG_FINALLY is set to the
> > beginning of the next page or queue head. This means we can lose
> > notifications that were copied but were not sent.
>
> True.
>
> > If we want to preserve the previous behavior, maybe we could use a new
> > local position while copying notifications and only advance the
> > "current" position while sending notifications to the frontend?
>
> That's not good. The loop advances 'current' before calling
> TransactionIdDidCommit() to ensure that if there's a broken entry in the
> queue for which TransactionIdDidCommit() throws an error, we advance
> 'current' past that point. Otherwise we would get back later to try to
> process the same broken entry again and again.
>

Ouch, I failed to realise that this try/catch saves us from
TransactionIdDidCommit failure too.

The comment around PG_TRY says:

    /*
     * It is possible that we fail while trying to send a message to our
     * frontend (for example, because of encoding conversion failure).  If

So I thought that it's the main reason we have try/catch here.


Best regards,
Arseniy Mukhin