On Mon, Sep 22, 2025 at 3:41 PM Shlok Kyal <[email protected]> wrote: > > On Thu, 18 Sept 2025 at 13:17, Ashutosh Sharma <[email protected]> wrote: > > > > > In addition to this, should anyone really need to query the skip > > reason if pg_replication_slots already shows that the slot is synced > > and not temporary? Ideally, users should check the slot status in > > pg_replication_slots, and if it indicates the slot is persisted, there > > seems little value in enquiring pg_stat_replication_slots for the skip > > reason. That said, it’s important to ensure the information in both > > views remains consistent. > > > I have a doubt. Why don't we want to report the sync skip reason once > the slots are persisted? > for the case: > > latestFlushPtr = GetStandbyFlushRecPtr(NULL); > if (remote_slot->confirmed_lsn > latestFlushPtr) > { > /* > * Can get here only if GUC 'synchronized_standby_slots' on the > * primary server was not configured correctly. > */ > ereport(AmLogicalSlotSyncWorkerProcess() ? LOG : ERROR, > errcode(ERRCODE_OBJECT_NOT_IN_PREREQUISITE_STATE), > errmsg("skipping slot synchronization because the > received slot sync" > " LSN %X/%08X for slot \"%s\" is ahead of the > standby position %X/%08X", > LSN_FORMAT_ARGS(remote_slot->confirmed_lsn), > remote_slot->name, > LSN_FORMAT_ARGS(latestFlushPtr))); > > return false; > } > > Slot sync skip can happen even for persistent slots. So why should we > avoid displaying the skip reason in such cases? >
We should display the skip reason even for persistent slots and clear the same after a successful sync. -- With Regards, Amit Kapila.
