On Thu, Sep 28, 2023 at 6:31 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > On 9/25/23 6:10 AM, shveta malik wrote: > > On Fri, Sep 22, 2023 at 3:48 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > >> > >> On Thu, Sep 21, 2023 at 9:16 AM shveta malik <shveta.ma...@gmail.com> > >> wrote: > >>> > >>> On Tue, Sep 19, 2023 at 10:29 AM shveta malik <shveta.ma...@gmail.com> > >>> wrote: > >>> > >>> Currently in patch001, synchronize_slot_names is a GUC on both primary > >>> and physical standby. This GUC tells which all logical slots need to > >>> be synced on physical standbys from the primary. Ideally it should be > >>> a GUC on physical standby alone and each physical standby should be > >>> able to communicate the value to the primary (considering the value > >>> may vary for different physical replicas of the same primary). The > >>> primary on the other hand should be able to take UNION of these values > >>> and let the logical walsenders (belonging to the slots in UNION > >>> synchronize_slots_names) wait for physical standbys for confirmation > >>> before sending those changes to logical subscribers. The intent is > >>> logical subscribers should never be ahead of physical standbys. > >>> > >> > >> Before getting into the details of 'synchronize_slot_names', I would > >> like to know whether we really need the second GUC > >> 'standby_slot_names'. Can't we simply allow all the logical wal > >> senders corresponding to 'synchronize_slot_names' to wait for just the > >> physical standby(s) (physical slot corresponding to such physical > >> standby) that have sent ' synchronize_slot_names'list? We should have > >> one physical standby slot corresponding to one physical standby. > >> > > > > yes, with the new approach (to be implemented next) where we plan to > > send synchronize_slot_names from each physical standby to primary, the > > standby_slot_names GUC should no longer be needed on primary. The > > physical standbys sending requests should automatically become the > > ones to be waited for confirmation on the primary. > > > > I think that standby_slot_names could be used to do some filtering (means > for which standby(s) we don't want the logical replication on the primary to > go > ahead and for which standby(s) one would allow it). >
Isn't it implicit that the physical standby that has requested 'synchronize_slot_names' should be ahead of their corresponding logical walsenders? Otherwise, after the switchover to the new physical standby, the logical subscriptions won't work. > I think that removing the GUC would: > > - remove this flexibility > I think if required we can add such a GUC later as well. Asking users to set more parameters also makes the feature less attractive, so I am trying to see if we can avoid this GUC. > - 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. 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. -- With Regards, Amit Kapila.
