On Sun, Jan 31, 2016 at 8:58 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Sun, Jan 31, 2016 at 5:28 PM, Masahiko Sawada <sawada.m...@gmail.com> > wrote: >> 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. > > If there are hooks, I don't think that we should really bother about > having in core anything more complicated than what we have now. The > trick will be to come up with a hook design modular enough to support > the kind of configurations mentioned on this thread. Roughly perhaps a > refactoring of the syncrep code so as it is possible to wait for > multiple targets some of them being optional,, one modular way in > pg_stat_get_wal_senders to represent the status of a node to user, and > another hook to return to decide which are the nodes to wait for. Some > of the nodes being waited for may be based on conditions for quorum > support. That's a hard problem to do that in a flexible enough way.
Hm, I think not-nested quorum and priority are not complicated, and we should support at least both or either simple method in core of postgres. More complicated method like using json-style, or dedicated language would be supported by external module. 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
