Re: Introduce XID age based replication slot invalidation - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: Introduce XID age based replication slot invalidation
Date
Msg-id CAD21AoArh6-RfOGGY6GfWqqHv0qUJEMwXVmGQk=29uYiKFLSgA@mail.gmail.com
Whole thread
In response to Re: Introduce XID age based replication slot invalidation  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Responses Re: Introduce XID age based replication slot invalidation
List 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



pgsql-hackers by date:

Previous
From: Alexandre Felipe
Date:
Subject: Re: SLOPE - Planner optimizations on monotonic expressions.
Next
From: Antonin Houska
Date:
Subject: Re: Adding REPACK [concurrently]