Re: pg_stat_replication.*_lag sometimes shows NULL during active replication
Fujii Masao <masao.fujii@gmail.com>
From: Fujii Masao <masao.fujii@gmail.com>
To: Shinya Kato <shinya11.kato@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2026-03-19T17:13:25Z
Lists: pgsql-hackers
Attachments
- v5-0001-Avoid-sending-duplicate-WAL-locations-in-standby-.patch (application/octet-stream) patch v5-0001
On Thu, Mar 19, 2026 at 10:58 PM Shinya Kato <shinya11.kato@gmail.com> wrote: > > On Tue, Mar 17, 2026 at 11:00 AM Fujii Masao <masao.fujii@gmail.com> wrote: > > > > On Mon, Mar 16, 2026 at 9:26 AM Shinya Kato <shinya11.kato@gmail.com> wrote: > > > Thank you for the v4 patch. I think this approach is better than mine. > > > I tested the patch and confirmed that the issue no longer reproduces > > > with physical replication. However, with logical replication, the lag > > > columns in pg_stat_replication still show NULL periodically at > > > wal_receiver_status_interval, since send_feedback() in worker.c can > > > still send duplicate positions. > > > > I was thinking that if a feedback message triggered by > > wal_receiver_status_interval has the same LSNs as the previous message, > > it's expected for the lag columns to become NULL. But you see it differently, > > don't you? Sorry, I failed to understand your point... > > Sorry for the confusion. I ran a script inserting one row every 0.5 > seconds under logical replication and confirmed that NULL still > appears in the lag columns even while replication is actively running. > I was initially mistaken that this was tied to > wal_receiver_status_interval timing — that turned out to be unrelated. > > I haven't had time to investigate further, but my current impression > is that the existing approach may not be sufficient for logical > replication. Thanks for the clarification! I understand your point now. I think the issue occurs when the positions in the first message point to the same LSN (e.g., 0/030D5230), and the second message reports the same but larger LSN (e.g., 0/030D52E0). I've updated the patch to address this. It removes fullyAppliedLastTime, tracks the positions from the previous reply, and clears the lag values only when the positions remain unchanged across two consecutive messages. Patch attached. Could you test and review this updated patch? Regards, -- Fujii Masao
Commits
-
Avoid sending duplicate WAL locations in standby status replies
- 400a790a48eb 19 (unreleased) landed
-
Fix premature NULL lag reporting in pg_stat_replication
- bf7ecf35318d 14.23 landed
- 246c296f00ae 15.18 landed
- f4210500156a 16.14 landed
- fdce5de552c2 17.10 landed
- 98e96e579b91 18.4 landed
- eef1ba704dde 19 (unreleased) landed