On Wed, Oct 14, 2015 at 10:38 AM, Michael Paquier <michael.paqu...@gmail.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?
