Horton

Re: Newly created replication slot may be invalidated by checkpoint

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Alexander Korotkov <aekorotkov@gmail.com>
Cc: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.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>, Masahiko Sawada <sawada.mshk@gmail.com>
Date: 2025-12-19T06:02:36Z
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 Thu, Dec 18, 2025 at 5:41 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
>
> On Thu, Dec 11, 2025 at 9:29 AM Zhijie Hou (Fujitsu)
> <houzj.fnst@fujitsu.com> wrote:
> > On Thursday, December 11, 2025 3:09 PM Zhijie Hou (Fujitsu) <houzj.fnst@fujitsu.com> wrote:
> > > I reviewed that approach, and I think the main distinction lies in whether to
> > > use a new LWLock to serialize the process or rely on an existing lock.
> > > Introducing a new LWLock in back branches would alter the size of
> > > MainLWLockArray and affect
> > > NUM_INDIVIDUAL_LWLOCKS/LWTRANCHE_FIRST_USER_DEFINED.
> > > Although this may not directly impact user applications since users typically
> > > use standard APIs like RequestNamedLWLockTranche and
> > > LWLockNewTrancheId to add private LWLocks, it still has a slight risk.
> > > Additionally, using an existing lock could keep code similarity with the HEAD,
> > > which can be helpful for future bug fixes and analysis.
> >
> > BTW, I searched the git history and can only find 2 old commits that adds lwlock
> > On stable branches, but both of are fixing serious problems such as
> > data corruption / loss issues.
>
> I understand that that was done due to more serious reasons than ours.
> As I get, it run smoothly.  At least, I can't remember we have been
> reported with any issues regarding to this change.  Can we assume this
> is kind of "tested" and add new LWLock to both master and back
> branches?  I think this would be good in terms of clarity and minimal
> possible divergence of back branches.
>

The impact of using the new lock on master is more because we need to
start using it in CheckPointReplicationSlots() to protect the WAL
reservation. Then, we also probably need to use new lock in
create/drop slot APIs. Or we can start using this new lock in addition
to ReplicationSlotAllocationLock in CheckPointReplicationSlots(). Yet
another possibility is to use a new lock while computing RedoRecPtr in
CreateCheckPoint. I am not sure that is an improvement for master as
compared to the way it is currently working.

-- 
With Regards,
Amit Kapila.