On Tue, Mar 24, 2026, 00:31 Fujii Masao <[email protected]> wrote:
> 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. > Thanks for the updated patch. LGTM. Regarding the backpatch, I'd personally appreciate it if the walsender.c changes were backpatched to stable branches. As you noted, it don't fully solve the reported issue, but they do help reduce the cases where lag columns in pg_stat_replication unexpectedly become NULL. Even a partial mitigation in the back branches would be valuable for users running stable releases. -- Best regards, Shinya Kato >
