On Tue, Feb 20, 2024 at 4:21 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Mon, Feb 19, 2024 at 12:14 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
>
> > > 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
> > ..."
>
> So why do we log a message about this?
>
This was added after the main commit of this functionality to find
some BF failures (where we were expecting the slot to sync but due to
one of these conditions not being met the slot was not synced) and we
can probably change it to DEBUG1 as well. I think we would need this
information w.r.t this functionality to gather more information in
case expected slots are not being synced and it may be helpful for
users to also know why the slots are not synced, if that happens.
--
With Regards,
Amit Kapila.