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: Kirill Reshke <reshkekirill@gmail.com>
Cc: Ashutosh Sharma <ashu.coek88@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-08-29T06:48:50Z
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 Thu, Aug 28, 2025 at 3:29 PM Kirill Reshke <reshkekirill@gmail.com> wrote:
>
> On Thu, 28 Aug 2025 at 14:56, Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Thu, Aug 28, 2025 at 11:07 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> > >
> > > We have seen cases where slot synchronization gets delayed, for example when the slot is behind the failover standby or vice versa, and the slot sync worker has to wait for one to catch up with the other. During this waiting period, users querying pg_replication_slots can only see whether the slot has been synchronized or not. If it has already synchronized, that’s fine, but if synchronization is taking longer, users would naturally want to understand the reason for the delay.
> > >
> > > Is there a way for end users to know the cause of slot synchronization delays, so they can take appropriate actions to speed it up?
> > >
> > > I understand that server logs are emitted in such cases, but logs are not something end users would want to check regularly. Moreover, since logging is configuration-based, relevant messages may sometimes be skipped or suppressed.
> > >
> >
> > Currently, the way to see the reason for sync skip is LOGs but I think
> > it is better to add a new column like sync_skip_reason in
> > pg_replication_slots. This can show the reasons like
> > standby_LSN_ahead_remote_LSN. I think ideally users can compare
> > standby's slot LSN/XMIN with remote_slot being synced. Do you have any
> > better ideas?
> >
>
> How about something like pg_stat_progress_replication_slot with remote
> LSN/standby LSN/catalog XID etc?
> Wouldn't this be in sync with all other debug pg_stat_progress* views
> and thus more Postgres-y?
>

Yes, that is another option. I am a little worried that it is not
always the sync lags behind, so having a separate view just for sync
progress may be too much. Yet another option is existing view
pg_stat_replication_slots but it seems sync progress doesn't directly
match there. For example, we can add a counter sync_skipped, time of
last sync_skip, and last_sync_skip_reason that could be sufficient to
dig the problem further.

-- 
With Regards,
Amit Kapila.