Horton

Re: Newly created replication slot may be invalidated by checkpoint

Masahiko Sawada <sawada.mshk@gmail.com>

View thread
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Vitaly Davydov <v.davydov@postgrespro.ru>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, "suyu.cmj" <mengjuan.cmj@alibaba-inc.com>, tomas <tomas@vondra.me>, michael <michael@paquier.xyz>, "bharath.rupireddyforpostgres" <bharath.rupireddyforpostgres@gmail.com>, Alexander Korotkov <aekorotkov@gmail.com>
Date: 2025-12-02T16:26:18Z
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. Prevent invalidation of newly synced replication slots.

  2. Prevent invalidation of newly created replication slots.

  3. Fix re-distributing previously distributed invalidation messages during logical decoding.

  4. Keep WAL segments by the flushed value of the slot's restart LSN

  5. Keep WAL segments by slot's last saved restart LSN

On Mon, Dec 1, 2025 at 10:19 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Tuesday, December 2, 2025 1:03 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Fri, Nov 21, 2025 at 12:14 AM Zhijie Hou (Fujitsu)
> > <houzj.fnst@fujitsu.com> wrote:
> > >
> > > OK, I think it makes sense to start separate threads.
> > >
> > > I have split the patches based on the different bugs they
> > > address and am sharing them here for reference.
> > >
> >
> > I'm reviewing the 0001 patch and the problem that can be addressed by
> > that patch. While the proposed patch addresses the race condition
> > between a checkpointing and newly created slot, could the same issue
> > happen between the checkpointing and copying a slot? I'm trying to
> > understand when we have to acquire ReplicationSlotAllocationLock in an
> > exclusive mode in the new lock scheme.
>
> Thanks for reviewing !
>
> I think the situation is somewhat different in the copy_replication_slot(). As
> noted in the comments[1], it's considered acceptable for WALs preceding the
> initial restart_lsn to be removed since the latest restart_lsn will be copied
> again in the second phase, so latest WAL being reserved is safe.

Right. But does it mean that the new slot could be invalidated while
being copied if the first copied restart_lsn becomes less than a new
redo ptr set by a concurrent checkpoint? I thought the problem the
0001 patch is trying to fix is that the slot could end up being
invalidated by a concurrent checkpoint even while being created, so I
wonder if the same problem could occur.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com