Re: Support for N synchronous standby servers - take 2

On Wed, Oct 14, 2015 at 10:38 AM, Michael Paquier <michael(dot)paquier(at)gmail(dot)com
> wrote:

> On Wed, Oct 14, 2015 at 3:02 AM, Masahiko Sawada wrote:
>
> > It would be good even if there are some restriction such as the
> > nesting level, the group setting.
> > The another new approach that I came up with is,
> > * Add new parameter synchronous_replication_method (say s_r_method)
> > which can have two names: 'priority', 'quorum'
> > * If s_r_method = 'priority', the value of s_s_names (e.g. 'n1,n2,n3')
> > is handled using priority. It's same as '[n1,n2,n3]' in dedicated
> > language.
> > * If s_r_method = 'quorum', the value of s_s_names is handled using
> > quorum commit, It's same as '(n1,n2,n3)' in dedicated language.
> > * Setting of synchronous_standby_names is same as today. That is, the
> > storing the nesting value is not supported.
> > * If we want to support more complex syntax like what we are
> > discussing, we can add the new value to s_r_method, for example
> > 'complex', 'json'.
>
> If we go that path, I think that we still would need an extra
> parameter to control the number of nodes that need to be taken from
> the set defined in s_s_names whichever of quorum or priority is used.
> Let's not forget that in the current configuration the first node
> listed in s_s_names and *connected* to the master will be used to
> acknowledge the commit.
>

Would it be better to just use a simple language instead of 3 different
parameters?

s_s_names = 2[X,Y,Z] # 2 priority
s_s_names = 1(A,B,C) # 1 quorum
s_s_names = R,S,T # default behavior: 1 priorty?