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

On Fri, Sep 12, 2025 at 1:07 PM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)com> wrote:
>
> On Mon, Sep 8, 2025 at 9:52 AM Ashutosh Sharma <ashu(dot)coek88(at)gmail(dot)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.

I think storing all 3 pieces of
> information - sync_skip_reason, sync_skip_count, and last_sync_skip in
> pg_stat_replication_slots would be a cleaner solution. This way, all
> the sync-related info stays together and the code remains
> straightforward.
>

Having all the sync information together has merit but don't you think
in this case the sync_skip_reason doesn't seem to be matching with the
existing columns in pg_stat_replication_slots?

--
With Regards,
Amit Kapila.