On Sat, Sep 21, 2024 at 6:34 AM John H <johnh...@gmail.com> wrote: > > On Fri, Sep 20, 2024 at 2:44 AM shveta malik <shveta.ma...@gmail.com> wrote: > > > > > > > > > > The difference is that the purpose of 'synchronized_standby_slots' is > > > to mention slot names for which the user expects logical walsenders to > > > wait before sending the logical changes to subscribers. OTOH, > > > 'synchronous_standby_names' has a different purpose as well. It is not > > > clear to me if the users would be interested in syncing failover slots > > > to all the standbys mentioned in 'synchronous_standby_names'. > > > > > > > Okay, I see your point. But not sure what could be the solution here > > except documenting. But let me think more. > > > > That's a great find. I didn't consider mixed physical and logical > replicas in synchronous_standby_names. > I wonder if there are users running synchronous_standby_names with a > mix of logical and > physical replicas and what the use case would be. >
I am also not aware of the actual use cases of mixing physical and logical synchronous standbys but as we provide that functionality, we can't ignore it. BTW, I am also not sure if users would like the slots to be synced on all the standbys mentioned in synchronous_standby_names. and even, if they are, it is better to have an explicit way of letting users specify it. One possible approach is to extend the syntax of "synchronized_standby_slots" similar to "synchronous_standby_names" so that users can directly specify slots similarly and avoid waiting for more than required standbys. -- With Regards, Amit Kapila.
