On Wed, Dec 6, 2023 at 3:00 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > Hi, > > On 12/6/23 7:18 AM, shveta malik wrote: > > On Wed, Dec 6, 2023 at 10:56 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > >> > >> I feel that is indirectly relying on the fact that the primary won't > >> advance logical slots unless physical standby has consumed data. > > > > Yes, that is the basis of this discussion. > > Yes. > > > But now on rethinking, if > > the user has not set 'standby_slot_names' on primary at first pace, > > then even if walreceiver on standby is down, slots on primary will > > keep on advancing > > Oh right, good point. > > > and thus we need to sync. > > Yes and I think our current check "XLogRecPtrIsInvalid(WalRcv->latestWalEnd)" > in synchronize_slots() prevents us to do so (as I think WalRcv->latestWalEnd > would be invalid for a non started walreceiver). >
But I think we do not need to deal with the case that walreceiver is not started at all on standby. It is always started. Walreceiver not getting started or down for long is a rare scenario. We have other checks too for 'latestWalEnd' in slotsync worker and I think we should retain those as is. > > We have no check currently > > that mandates users to set standby_slot_names. > > > > Yeah and OTOH unset standby_slot_names is currently the only > way for users to "force" advance failover slots if they want to (in case > say the standby is down for a long time and they don't want to block logical > decoding > on the primary) as we don't provide a way to alter the failover property > (unless connecting with replication which sounds more like a hack). > yes, right. > >> Now, > >> it is possible that slot-sync worker lags behind and still needs to > >> sync more data for slots in which it makes sense for slot-sync worker > >> to be alive. > > Right. > > Regards, > > -- > Bertrand Drouvot > PostgreSQL Contributors Team > RDS Open Source Databases > Amazon Web Services: https://aws.amazon.com
