Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication
| От | Fujii Masao |
|---|---|
| Тема | Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication |
| Дата | |
| Msg-id | CAHGQGwFXKtwmqDrUE_pxVj4rVYcjy0VXP64hTcm30zLkp3G4qw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: pg_recvlogical: Prevent flushed data from being re-sent after restarting replication (Chao Li <li.evan.chao@gmail.com>) |
| Список | pgsql-hackers |
On Wed, Jan 14, 2026 at 5:47 PM Chao Li <li.evan.chao@gmail.com> wrote: > > > > > On Jan 14, 2026, at 09:26, Fujii Masao <masao.fujii@gmail.com> wrote: > > > > On Mon, Jan 12, 2026 at 4:08 PM Chao Li <li.evan.chao@gmail.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 shouldwe 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 beenupdated > > So, I withdraw this comment. > > V5 LGTM. Thanks for the review! I've pushed the patches. Regards, -- Fujii Masao
В списке pgsql-hackers по дате отправления: