On Thu, Nov 20, 2025 at 4:07 PM Zhijie Hou (Fujitsu) <[email protected]> wrote: > > On Thursday, November 20, 2025 4:26 PM Vitaly Davydov > <[email protected]> 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.
