On Wed, Oct 4, 2023 at 5:00 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Wed, Oct 4, 2023 at 11:55 AM Drouvot, Bertrand > <bertranddrouvot...@gmail.com> wrote: > > > > On 10/4/23 6:26 AM, shveta malik wrote: > > > On Wed, Oct 4, 2023 at 5:36 AM Amit Kapila <amit.kapil...@gmail.com> > > > wrote: > > >> > > >> > > >> How about an alternate scheme where we define sync_slot_names on > > >> standby but then store the physical_slot_name in the corresponding > > >> logical slot (ReplicationSlotPersistentData) to be synced? So, the > > >> standby will send the list of 'sync_slot_names' and the primary will > > >> add the physical standby's slot_name in each of the corresponding > > >> sync_slot. Now, if we do this then even after restart, we should be > > >> able to know for which physical slot each logical slot needs to wait. > > >> We can even provide an SQL API to reset the value of > > >> standby_slot_names in logical slots as a way to unblock decoding in > > >> case of emergency (for example, corresponding when physical standby > > >> never comes up). > > >> > > > > > > > > > Looks like a better approach to me. It solves most of the pain points > > > like: > > > 1) Avoids the need of multiple GUCs > > > 2) Primary and standby need not to worry to be in sync if we maintain > > > sync-slot-names GUC on both > > As per my understanding of this approach, we don't want > 'sync-slot-names' to be set on the primary. Do you have a different > understanding? >
Same understanding. We do not need it to be set on primary by user. It will be GUC on standby and standby will convey it to primary. > > > 3) User still gets the flexibility to remove a standby from wait-lost > > > of primary's logical-walsenders' using reset SQL API. > > > > > > > Fully agree. > > > > > Now some initial thoughts: > > > 1) Since each logical slot could be needed to be synched by multiple > > > physical-standbys, so in ReplicationSlotPersistentData, we need to > > > hold a list of standby's name. So this brings us to question as in how > > > much shall we allocate initially in shared-memory? Shall it be for > > > max_replication_slots (worst case scenario) in each > > > ReplicationSlotPersistentData to hold physical-standby names? > > > > > > > Yeah, and even if we do the opposite means add the 'to-sync' > > logical replication slot in the ReplicationSlotPersistentData of the > > physical > > slot(s) the questions still remain (as a physical standby could want to > > sync multiples slots) > > > > I think we don't need to allocate the entire max_replication_slots > array in ReplicationSlotPersistentData. We should design something > like the variable amount of data to be written on disk should be > represented similar to what we do with variable TransactionIds in > SnapBuildOnDisk. Now, we also need to store the list of standby's > in-memory either shared or local memory of walsender. I think storing > it in shared-memory say in ReplicationSlot has the advantage that we > can easily set that via physical walsender and it may be easier to > maintain both for manually created logical slots and logical slots > associated with logical walsenders. But still this needs some thoughts > as to what is the best way to store this information. > Thanks for the idea, I will review this. thanks Shveta
