Horton

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

Ashutosh Sharma <ashu.coek88@gmail.com>

View thread
From: Ashutosh Sharma <ashu.coek88@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Shlok Kyal <shlok.kyal.oss@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-09-12T11:57:59Z
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.

Hi Amit,

On Fri, Sep 12, 2025 at 4:24 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Fri, Sep 12, 2025 at 1:07 PM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> >
> > On Mon, Sep 8, 2025 at 9:52 AM Ashutosh Sharma <ashu.coek88@gmail.com> wrote:
> > >
> > > I think we can do that, since sync_skip_reason appears to be a
> > > descriptive metadata rather than statistical data like
> > > slot_sync_skip_count and last_slot_sync_skip. However, it's also true
> > > that all three pieces of data are transient by nature - they will just
> > > be present in the runtime.
> > >
> >
> > After spending some more time on this, I found that maintaining
> > sync_skip_reason in pg_replication_slots would make the code changes a
> > bit messy and harder to maintain.
> >
>
> What exactly is your worry? It seems more logical to have
> sync_skip_reason in pg_replication_slots and other two in
> pg_stat_replication_slots as the latter is purely a stats view and the
> sync_skip_count/last_sync_skip suits there better.
>

The code changes for adding the skip reason to pg_replication_slots
feel a bit hacky compared to the approach for incorporating all three
pieces of information in pg_stat_replication_slots. I thought many
might prefer simplicity over hackiness, which is why having everything
in pg_stat_replication_slots could be more acceptable. That said, we
could maybe prepare a POC patch with this approach as well, compare
the two, and then decide which path to take.

--
With Regards,
Ashutosh Sharma.