On Mon, Feb 19, 2024 at 12:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> On Mon, Feb 19, 2024 at 11:42 AM Robert Haas <robertmhaas@gmail.com> wrote:
> >
> > On Mon, Feb 19, 2024 at 11:04 AM Kyotaro Horiguchi
> > <horikyota.ntt@gmail.com> wrote:
> > > Or I thought the values could be moved to DETAILS: line.
> >
> > Yeah, I think that's likely to be the right approach here. The details
> > aren't too clear to me.
> >
> > Does the primary error message really need to say "could not sync
> > slot"? If it will be obvious from context that we were trying to sync
> > a slot, then it would be fine to just say "ERROR: remote slot precedes
> > local slot".
> >
>
> As this is a LOG message, I feel one may need some more information on
> the context but it is not mandatory.
>
> > But I also don't quite understand what problem this is trying to
> > report. Is this slot-syncing code running on the primary or the
> > standby? If it's running on the primary, then surely it's expected
> > that the remote slot will precede the local one. And if it's running
> > on the standby, then the comments in
> > update_and_persist_local_synced_slot about waiting for the remote side
> > to catch up seem quite confusing, because surely we're chasing the
> > primary and not the other way around?
> >
>
> The local's restart_lsn could be ahead of than primary's for the very
> first sync when the WAL corresponding to the remote's restart_lsn is
> not available on standby (say due to a different wal related settings
> the required WAL has been removed when we first time tried to sync the
> slot). For more details, you can refer to comments atop slotsync.c
> starting from "If the WAL corresponding to the remote's restart_lsn
> ..."
>
Sorry, I gave the wrong reference, the comments I was referring to
start with: "If on physical standby, the WAL corresponding ...".
--
With Regards,
Amit Kapila.