Hello, At Thu, 4 Feb 2016 23:06:45 +0300, Michael Paquier <michael.paqu...@gmail.com> wrote in <CAB7nPqTMV5sZkemGf=swmya8qpzv2vw9brrysxtkzusvk99...@mail.gmail.com> > On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier > <michael.paqu...@gmail.com> wrote: > > Sorry. Perhaps I am tired... I was just wondering if it would be fine > > to only support configurations up to one level of nested objects, like > > that: > > 2[node1, node2, node3] > > node1, 2[node2, node3], node3 > > In short, we could restrict things so as we cannot define a group of > > nodes within an existing group. > > No, actually, that's stupid. Having up to two nested levels makes more > sense, a quite common case for this feature being something like that: > 2{node1,[node2,node3]} > In short, sync confirmation is waited from node1 and (node2 or node3). > > Flattening groups of nodes with a new catalog will be necessary to > ease the view of this data to users: > - group name? > - array of members with nodes/groups > - group type: quorum or priority > - number of items to wait for in this group
Though I personally love the format, I don't fully recognize what the upcoming consensus is and the discussion looks to be looping back to the past, so please forgive me to confirm the current discussion status. We are coming to agree to have configuration manner including syntax which is compatible with future possible use, I think this is correct. (Though I haven't seen it explicitly written upthread, ) we regard it as important to keep validity of previous setting using s_s_names as 1-priority method. Is this correct? The most promising syntax is now considered as n-level quorum/priority nesting as Michael's proposal above. Correct? But aiming to 9.6, we are to support (1 or 2)-levels quorum *or* priority setup with the subset of the syntax. I don't think this is fully agreed yet. We don't consider using extension or some plugin mechanism for additional configuration method for this feature at least as of 9.6. Correct? I proposed that s_s_method for backward compatibility, but there is a voice that such a way of changing the semantics of s_s_names is confising. I can be in sympathy with him. If so, do we have another variable (named standbys_definition or likewise?) which is to be set alternatively with s_s_names? Or take another way? Sorry for the maybe-noise in advance. 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