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. thanks Shveta
