On Sat, Mar 21, 2026 at 11:05 AM Shinya Kato <[email protected]> wrote: > > On Fri, Mar 20, 2026 at 2:13 AM Fujii Masao <[email protected]> wrote: > > 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). > > Thanks for the explanation! > > > 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? > > The patch works properly. I think it looks nice to me, except for the > typo I sent in the previous message.
Thanks for the review! I've fixed the typo and attached an updated patch. I also incorporated Chao's comments from upthread. I'm planning to commit this to master. As for backpatching, I'm hesitant to backpatch the full patch since it may reduce the number of replication feedback messages, which feels too invasive for stable branches. That said, the patch's changes in walsender.c could be backpatched. As discussed earlier, they don't fully address the reported issue, but they do help mitigate cases where lag becomes NULL unexpectedly in logical replication. So it might be worth considering those changes for stable branches. Thoughts? Regards, -- Fujii Masao
v6-0001-Avoid-sending-duplicate-WAL-locations-in-standby-.patch
Description: Binary data
