On Mon, Dec 11, 2023 at 1:22 PM Drouvot, Bertrand <bertranddrouvot...@gmail.com> wrote: > > Hi, > > On 12/8/23 10:06 AM, Amit Kapila wrote: > > On Wed, Dec 6, 2023 at 4:53 PM shveta malik <shveta.ma...@gmail.com> wrote: > >> > >> PFA v43, changes are: > >> > > > > I wanted to discuss 0003 patch about cascading standby's. It is not > > clear to me whether we want to allow physical standbys to further wait > > for cascading standby to sync their slots. If we allow such a feature > > one may expect even primary to wait for all the cascading standby's > > because otherwise still logical subscriber can be ahead of one of the > > cascading standby. > > I've the same feeling here. I think it would probably be expected that > the primary also wait for all the cascading standby. > > > I feel even if we want to allow such a behaviour we > > can do it later once the main feature is committed. > > Agree. > > > I think it would > > be good to just allow logical walsenders on primary to wait for > > physical standbys represented by GUC 'standby_slot_names'. > > That makes sense for me for v1. > > > If we agree > > on that then it would be good to prohibit setting this GUC on standby > > or at least it should be a no-op even if this GUC should be set on > > physical standby. > > I'd prefer to completely prohibit it on standby (to make it very clear it's > not > working at all) as long as one can enable it without downtime once the standby > is promoted (which is the case currently).
And I think slot-sync worker should exit as well on cascading standby. Thoughts? If we agree on the above, then we need to look for a way to distinguish between first and cascading standby. I could not find any existing way to do so. One possible approach is to connect to the remote using PrimaryConninfo and run 'pg_is_in_recovery()' there, if it returns true, then it means we are cascading standby. Any simpler way to achieve this? thanks Shveta
