On Mon, Oct 2, 2023 at 11:39 AM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 9/29/23 1:33 PM, Amit Kapila wrote: > > On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand > > <bertranddrouvot...@gmail.com> wrote: > >> > > > >> - probably open corner cases like: what if a standby is down? would that > >> mean > >> that synchronize_slot_names not being send to the primary would allow the > >> decoding > >> on the primary to go ahead? > >> > > > > Good question. BTW, irrespective of whether we have > > 'standby_slot_names' parameters or not, how should we behave if > > standby is down? Say, if 'synchronize_slot_names' is only specified on > > standby then in such a situation primary won't be even aware that some > > of the logical walsenders need to wait. > > Exactly, that's why I was thinking keeping standby_slot_names to address > this scenario. In such a case one could simply decide to keep or remove > the associated physical replication slot from standby_slot_names. Keep would > mean "wait" and removing would mean allow to decode on the primary. > > > OTOH, one can say that users > > should configure 'synchronize_slot_names' on both primary and standby > > but note that this value could be different for different standby's, > > so we can't configure it on primary. > > > > Yeah, I think that's a good use case for standby_slot_names, what do you > think? >
But, even if we keep 'standby_slot_names' for this purpose, the primary doesn't know the value of 'synchronize_slot_names' once the standby is down and or the primary is restarted. So, how will we know which logical WAL senders needs to wait for 'standby_slot_names'? -- With Regards, Amit Kapila.
