On Wed, Oct 14, 2015 at 3:16 AM, Josh Berkus <j...@agliodbs.com> wrote: > On 10/13/2015 11:02 AM, Masahiko Sawada wrote: >> I thought that this feature for postgresql should be simple at first >> implementation. >> 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 >> laguage. >> * 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. > > Well, the first question is: can you implement both of these things for > 9.6, realistically? > If you can implement them, then we can argue about > configuration format later. It's even possible that the nature of your > implementation will enforce a particular syntax. > > For example, if your implementation requires sync groups to be named, > then we have to include group names in the syntax. If you can't > implement nesting in the near future, there's no reason to have a syntax > for it.
Yes, I can implement both without nesting. The draft patch of replication using priority is already implemented by Michael, so I need to implement simple quorum commit logic and merge them. >> * 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'. > > I think having two different syntaxes is a bad idea. I'd rather have a > wholly proprietary configuration markup than deal with two alternate ones. > I agree, we should choice either. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
