Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication

> On Jan 14, 2026, at 09:26, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Mon, Jan 12, 2026 at 4:08 PM Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com> wrote:
>> Thanks for the patch. Here are my comments on v4.
>
> Thanks for the review!
>
>
>> 1 - 0001
>> ```
>> + /*
>> + * Save the last flushed position as the replication start point. On
>> + * reconnect, replication resumes from there to avoid re-sending flushed
>> + * data.
>> + */
>> + startpos = output_fsync_lsn;
>> ```
>>
>> Looking at function OutputFsync(), fsync() may fail and there a few branches to return early without fsync(), so should we only update startpos after fsync()?
>
> Maybe not, but I might be missing something. Could you clarify what
> concrete scenario would be problematic with the current code?
>

I just reviewed the patch again, and I think I was wrong wrt this comment:

* If fsync() fails, the process will fail out, no reconnect will happen, so wether or not updating startpos doesn’t matter;
* if (fsync_interval <= 0), fsync is not required, but we still need to update startpos
* if (!output_needs_fsync), meaning nothing new to fsync, but we still need to update startpos if startpos has not been updated

So, I withdraw this comment.

V5 LGTM.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/