On Sun, Jan 31, 2016 at 5:18 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sun, Jan 31, 2016 at 5:08 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> On Sun, Jan 31, 2016 at 1:17 PM, Michael Paquier >> <michael.paqu...@gmail.com> wrote: >>> On Thu, Jan 28, 2016 at 10:10 PM, Masahiko Sawada wrote: >>>> By the discussions so far, I'm planning to have several replication >>>> methods such as 'quorum', 'complex' in the feature, and the each >>>> replication method specifies the syntax of s_s_names. >>>> It means that s_s_names could have the number of sync standbys like >>>> what current patch does. >>> >>> What if the application_name of a standby node has the format of an integer? >> >> Even if the standby has an integer as application_name, we can set >> s_s_names like '2,1,2,3'. >> The leading '2' is always handled as the number of sync standbys when >> s_r_method = 'priority'. > > Hm. I agree with Fujii-san here, having the number of sync standbys > defined in a parameter that should have a list of names is a bit > confusing. I'd rather have a separate GUC, which brings us back to one > of the first patches that I came up with, and a couple of people, > including Josh were not happy with that because this did not support > real quorum. Perhaps the final answer would be really to get a set of > hooks, and a contrib module making use of that.
Yeah, I agree with having set of hooks, and postgres core has simple multi sync replication mechanism like you suggested at first version. 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
