Re: How can end users know the cause of LR slot sync delays?

On Mon, Sep 22, 2025 at 3:41 PM Shlok Kyal <shlok.kyal.oss@gmail.com> wrote:
>
> On Thu, 18 Sept 2025 at 13:17, Ashutosh Sharma <ashu.coek88@gmail.com> 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.