On Thu, Dec 7, 2023 at 1:19 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > Hi, > > On 12/6/23 11:58 AM, shveta malik wrote: > > 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. > > > > Agree to not deal with the walreceiver being down for now (we can > still improve that part later if we encounter the case in the real > world). >
yes, agreed. > Might be worth to add comments in the code (around the WalRcv->latestWalEnd > checks) that no "lagging" sync are possible if the walreceiver is not started > though? > I am a bit confused. Do you mean as a TODO item? Otherwise the comment will be opposite of the code we are writing. > > Regards, > > -- > Bertrand Drouvot > PostgreSQL Contributors Team > RDS Open Source Databases > Amazon Web Services: https://aws.amazon.com
