> On Mar 23, 2026, at 23: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.
>
> Thoughts?
>
> Regards,
>
> --
> Fujii Masao
> <v6-0001-Avoid-sending-duplicate-WAL-locations-in-standby-.patch>
Thank you for updating the patch. I saw that the variable name and function
name were changed to reflect my earlier comments.
v6 looks good to me.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/
