Re: Synchronizing slots from primary to standby
От | Amit Kapila |
---|---|
Тема | Re: Synchronizing slots from primary to standby |
Дата | |
Msg-id | CAA4eK1L3vTXcg-vV9HvahMRdTpDa6bEwb=YX4WvFYgJQ+uEunw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Synchronizing slots from primary to standby (shveta malik <shveta.malik@gmail.com>) |
Ответы |
Re: Synchronizing slots from primary to standby
|
Список | pgsql-hackers |
On Thu, Sep 21, 2023 at 9:16 AM shveta malik <shveta.malik@gmail.com> wrote: > > On Tue, Sep 19, 2023 at 10:29 AM shveta malik <shveta.malik@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. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: