Horton

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

Chao Li <li.evan.chao@gmail.com>

View thread View on postgr.es
From: Chao Li <li.evan.chao@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2025-10-18T00:16:01Z
Lists: pgsql-hackers 

> On Oct 17, 2025, at 22:28, Fujii Masao <masao.fujii@gmail.com> wrote:
> 
> On Fri, Oct 17, 2025 at 5:11 PM Chao Li <li.evan.chao@gmail.com> wrote:
>> It took me some time to understand this fix. My most confusing was that once overwrite happens, how a reader head to catch up again? Finally I figured it out:
>> 
>> ```
>> +               lag_tracker->read_heads[head] =
>> +                       (lag_tracker->write_head + 1) % LAG_TRACKER_BUFFER_SIZE;
>> ```
>> 
>> "(lag_tracker->write_head + 1) % LAG_TRACKER_BUFFER_SIZE” points to the oldest LSN in the ring, from where an overflowed reader head starts to catch up.
>> 
>> I have no comment on the code change. Nice patch!
> 
> Thanks for the review!
> 
> I've updated the source comment to make the code easier to understand.
> The updated patch is attached.
> 
> <v2-0001-Fix-stalled-lag-columns-in-pg_stat_replication-wh.patch>

Thanks for adding the comment.

I think I put all concentration on the big picture yesterday, so I ignored this implementation detail:

```
+		if (lag_tracker->overflowed[head].lsn > lsn)
+			return now - lag_tracker->overflowed[head].time;
```

Should this “>” be “>=“?

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

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.