On Wed, Jul 2, 2025 at 8:20 PM vignesh C <vignes...@gmail.com> wrote: > On Sun, 29 Jun 2025 at 11:52, Hayato Kuroda (Fujitsu) > <kuroda.hay...@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
