On Thu, Mar 19, 2026 at 10:58 PM Shinya Kato <[email protected]> wrote: > > On Tue, Mar 17, 2026 at 11:00 AM Fujii Masao <[email protected]> wrote: > > > > On Mon, Mar 16, 2026 at 9:26 AM Shinya Kato <[email protected]> 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
v5-0001-Avoid-sending-duplicate-WAL-locations-in-standby-.patch
Description: Binary data
