Re: Support for N synchronous standby servers - take 2

Hello,

At Tue, 9 Feb 2016 13:31:46 +0900, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqSJgDLLsVk_Et-O=NBfJNqx3GbHszCYGvuTLRxHaZV3xQ(at)mail(dot)gmail(dot)com>
> On Tue, Feb 9, 2016 at 1:16 PM, Kyotaro HORIGUCHI
> >> > Anyway that's not a small project, and perhaps I am over-complicating
> >> > the whole thing.
> >> >
> >> > Thoughts?
> >>
> >> I agree that we would need something like such new view in the future,
> >> however it seems too late to work on that for 9.6 unfortunately.
> >> There is only one CommitFest left. Let's focus on very simple case, i.e.,
> >> 1-level priority list, now, then we can extend it to cover other cases.
> >>
> >> If we can commit the simple version too early and there is enough
> >> time before the date of feature freeze, of course I'm happy to review
> >> the extended version like you proposed, for 9.6.
> >
> > I agree to Fujii-san. There would be many of convenient gadgets
> > around this and they are completely welcome, but having
> > fundamental functionality in 9.6 seems to be far benetifical for
> > most of us.
>
> Hm. Rushing features in because we need them now is not really
> community-like. I'd rather not have us taking decisions like that
> knowing that we may pay a certain price in the long-term, while it
> pays in the short term, aka the 9.6 release. However, having a base in
> place for the mini-language would give enough room for future
> improvements, so I am fine with having only 1-level of nesting, with
> {} and [] supported. This can as well be simply represented within
> pg_stat_replication because we'd have basically only one group of
> nodes for now (if I got the idea correctly), the and status of each
> entry in pg_stat_replication would just need to reflect either
> potential or sync, which is something that now users are used to.

I agree to be more prudent for more 'stiff', a
hard-to-modify-later things. But if once we decede to use []{}
format at the beginning (I believe) for this feature, it is
surely nextensible enough and 1-level of replication sets is
sufficient to cover many new cases and make implement
simple. Internal structure can be evolutionary in contrast to its
user interface. Such a way of development is I don't think not
community-like, concerning the cases like this.

Anyway thank you very much for understanding.

> So, if I got the vibe correctly, we would basically just allow that in
> a first shot:
> N{node_list}, to define a priority group
> N[node_list], to define a quorum group
> There can be only one group, and elements in a node list cannot be a
> group. No need of group names either.
> --

That's quite reasonable for the first release of this feature. We
can/should consider the extensibility of the implement of this
feature through reviewing.

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center