Horton

Re: Fix lag columns in pg_stat_replication not advancing when replay LSN stalls

Fujii Masao <masao.fujii@gmail.com>

View thread View on postgr.es
From: Fujii Masao <masao.fujii@gmail.com>
To: Shinya Kato <shinya11.kato@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Chao Li <li.evan.chao@gmail.com>
Date: 2025-10-20T23:44:48Z
Lists: pgsql-hackers 
On Mon, Oct 20, 2025 at 1:45 PM Shinya Kato <shinya11.kato@gmail.com> wrote:
>
> On Mon, Oct 20, 2025 at 10:17 AM Fujii Masao <masao.fujii@gmail.com> wrote:
> >
> > On Sun, Oct 19, 2025 at 2:04 AM Shinya Kato <shinya11.kato@gmail.com> wrote:
> > > Thank you for the patch. I have one comment.
> > >
> > > +       if (lag_tracker->overflowed[head].lsn > lsn)
> > > +           return now - lag_tracker->overflowed[head].time;
> > >
> > > Could this return a negative value if the clock somehow went
> > > backwards? The original code returns -1 in this case, so I'm curious
> > > about this.
> >
> > Thanks for the review!
> >
> > Yes, you're right. So I've updated the patch so that -1 is returned
> > when the current time is earlier than the time in the overflow entry,
> > treating it as "no new sample found".
>
> Thank you for updating the patch. It looks nice to me.

Thanks for the review!
Unless there are any objections, I'll commit the patch and
backpatch it to all supported branches.

Regards,

-- 
Fujii Masao

Commits

  1. Add comments explaining overflow entries in the replication lag tracker.

  2. Fix stalled lag columns in pg_stat_replication when replay LSN stops advancing.