On Wed, Oct 14, 2015 at 5:58 PM, Beena Emerson <memissemer...@gmail.com> wrote: > > > 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?
Yeah, the main use case for this feature would just be that for most users: s_s_names = 2[dc1_standby,1(dc2_standby1, dc2_standby2)] Meaning that we wait for dc1_standby, which is a standby on data center 1, and one of the dc2_standby* set which are standbys in data center 2. So the following minimal characteristics would be needed: - support for priority selectivity for N nodes - support for quorum selectivity for N nodes - support for nested set of nodes, at least 2 level deep. The requirement to define a group of nodes also would not be needed. If we have that, I would say that we already do better than OrXXXe and MyXXL, to cite two of them. And if we can get that for 9.6 or even 9.7, that would be really great. Regards, -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
