Hello, At Tue, 9 Feb 2016 13:31:46 +0900, Michael Paquier <michael.paqu...@gmail.com> wrote in <CAB7nPqSJgDLLsVk_Et-O=nbfjnqx3gbhszcygvutlrxhazv...@mail.gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers