Horton

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

Amit Kapila <amit.kapila16@gmail.com>

View thread
From: Amit Kapila <amit.kapila16@gmail.com>
To: Shlok Kyal <shlok.kyal.oss@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-22T11:38:13Z
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. Rename column slotsync_skip_at to slotsync_last_skip.

  2. Add slotsync_skip_reason column to pg_replication_slots view.

  3. Fix test failure caused by commit 76b78721ca.

  4. Fix a BF failure caused by commit 76b78721ca.

  5. Add slotsync skip statistics.

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.