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: "Zhijie Hou (Fujitsu)" <houzj.fnst@fujitsu.com>
Cc: 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-11-20T10:44:10Z
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, Nov 20, 2025 at 4:07 PM Zhijie Hou (Fujitsu)
<houzj.fnst@fujitsu.com> wrote:
>
> On Thursday, November 20, 2025 4:26 PM Vitaly Davydov <v.davydov@postgrespro.ru> wrote:
>
> >
> > Concerning reserve_wal_for_local_slot. It seems it is used in synchronization
> > of failover logical slots. For me, it is tricky to change restart_lsn of a synced
> > logical slot to RedoRecPtr, because it may lead to problems with logical
> > replication using such slot after the replica promotion. But it seems it is the
> > architectural problem and it is not related to the problems, solved by the
> > patch.
>
> I think this is not an issue because if we use the redo pointer instead of the
> remote restart_lsn as the initial value, the synced slot won't be marked as
> sync-ready, so user cannot use it after promotion (also well documented). This
> is also the existing behavior before the patch, e.g., if the required WALs were
> removed, the oldest available WAL was used as the initial value, similarly
> resulting in the slot not being sync-ready.
>

Would it be better to discuss this in a separate thread? Though this
is related to original problem but still in a separate part of code
(slotsync) which I think can have a separate fix especially when the
fix is also somewhat different.

> >
> > The change of lock mode to EXCLUSIVE in
> > ReplicationSlotsComputeRequiredLSN may affect the performance when a lot
> > of slots are advanced during some small period of time. It may affect the
> > walsender performance. It advances the logical or physical slots when receive
> > a confirmation from the replica. I guess, the slot advancement may be pretty
> > frequent operation.
>
> Yes, I had the same thought and considered a simple alternative (similar to your
> suggestion below): use an exclusive lock only when updating the slot.restart_lsn
> during WAL reservation, while continuing to use a shared lock in the computation
> function. Additionally, place XLogSetReplicationSlotMinimumLSN() under the lock.
> This approach will also help serialize the process.
>

Can we discuss this as well in a separate thread?

-- 
With Regards,
Amit Kapila.