On Wed, Jul 2, 2025 at 8:20 PM vignesh C <vignesh21@gmail.com> wrote:
> On Sun, 29 Jun 2025 at 11:52, Hayato Kuroda (Fujitsu)
> <kuroda.hayato@fujitsu.com> wrote:
> >
> > Dear hackers,
> >
> > Thanks everyone who are working on the bug. IIUC the remained task is
> > to add code comments for avoiding the same mistake again described here:
> >
> > > Sounds reasonable. As per analysis till now, it seems removal of new
> > > assert is correct and we just need to figure out the reason in all
> > > failure cases as to why the physical slot's restart_lsn goes backward,
> > > and then add a comment somewhere to ensure that we don't repeat a
> > > similar mistake in the future.
> >
> > I've wrote a draft for that. How do you think?
>
> I analyzed a scenario involving physical replication where the
> restart_lsn appears to go backward by fewer files:
This is indeed an interesting case. But does restart_lsn go so much
backwards in this case? I've checked the logs. It looks like standby
requested a position several segments back, but restart_lsn keeps
increasing.
> I'm ok with adding the comments.
Thank you for your feedback!
------
Regards,
Alexander Korotkov
Supabase
