Re: Introduce XID age based replication slot invalidation
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Srinath Reddy Sadipiralla <srinath2133@gmail.com>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>,
John H <johnhyvr@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2026-04-06T08:44:52Z
Lists: pgsql-hackers
On Sun, Apr 5, 2026 at 7:52 PM Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote: > > Hi, > > On Sun, Apr 5, 2026 at 1:03 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote: > > > > Thank you for updating the patch! > > > > I've made some changes including moving MaybeInvalidateXidAgedSlot() > > to vacuum.c since the function seems more inherently tied to vacuum > > context. Also, updated the commit message and fixed typos. > > > > Please review the attached patch. > > Thank you Sawada-san! > > I took a look at the v10 patch and it LGTM. I tested it - make > check-world passes, pgindent doesn't complain. > While reviewing the patch, I found that with this patch, backend processes and autovacuum workers can simultaneously attempt to invalidate the same slot for the same reason. When invalidating a slot, we send a signal to the process owning the slot and wait for it to exit and release the slot. If the process takes a long time to exit for some reason, subsequent autovacuum workers attempting to invalidate the same slot will also send a SIGTERM and get stuck at InvalidatePossiblyObsoleteSlot(). In the worst case, this could result in all autovacuum activity being blocked. I think we need to address this problem. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix the handling of two GUCs during upgrade.
- 72e6c08fea7c 19 (unreleased) cited