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

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

From: Arseniy Mukhin <arseniy.mukhin.dev@gmail.com>
To: Matheus Alcantara <matheusssilv97@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Álvaro Herrera <alvherre@kurilemu.de>, Joel Jacobson <joel@compiler.org>, Rishu Bagga <rishu.postgres@gmail.com>, Yura Sokolov <y.sokolov@postgrespro.ru>, Daniil Davydov <3danissimo@gmail.com>, Alexandra Wang <alexandra.wang.oss@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>, Tom Lane <tgl@sss.pgh.pa.us>
Date: 2025-10-25T13:08:41Z
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

Attachments

On Sat, Oct 25, 2025 at 3:33 AM Matheus Alcantara
<matheusssilv97@gmail.com> wrote:
>
> On Fri Oct 24, 2025 at 4:36 AM -03, Arseniy Mukhin wrote:
> >> I would expect to add 002_aborted_tx_notifies.pl in a separate patch
> >> since it's not related to this bug fix.
> >>
> >> ---
> >> +# Test checks that listeners do not receive notifications from aborted
> >> +# transaction even if notifications have been added to the listen/notify
> >> +# queue. To reproduce it we use the fact that serializable conflicts
> >> +# are checked after tx adds notifications to the queue.
> >>
> >> I wonder if we could implement this test using the isolation test
> >> instead of the tap test. Is there any reason why you used a tap test
> >> for that?
> >>
> >
> > I agree it's less relevant to the patch now than it was with the new
> > 'committed' field approach. And there is no particular reason why it
> > was implemented as a TAP test actually.. So +1 to move it to separate
> > patch (does it mean to separate thread as well or just separate patch
> > file?) and rewrite as an isolation test (IIUC it's better to use
> > isolation test infrastructure if it's possible). I can try to do it if
> > nobody else does it earlier.
> >
> On the v11 version that I've sent on [1] I've move this test into a
> separate patch, please feel free to implement it as an isolation test if
> you want it.
>

Thank you!

I reimplemented the test in 0002 as an isolation test and added the
commit message. PFA the new version.


Best regards,
Arseniy Mukhin