On Mon, Feb 19, 2024 at 12:14 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Mon, Feb 19, 2024 at 11:42 AM Robert Haas <robertmh...@gmail.com> wrote: > > > > On Mon, Feb 19, 2024 at 11:04 AM Kyotaro Horiguchi > > <horikyota....@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.
