Re: Support for N synchronous standby servers - take 2

Hello,

At Thu, 4 Feb 2016 23:06:45 +0300, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote in <CAB7nPqTMV5sZkemGf=SWMyA8QpzV2VW9bRrysXtKzuSVk99ocw(at)mail(dot)gmail(dot)com>
> On Thu, Feb 4, 2016 at 10:49 PM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)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