On Thu, Sep 11, 2014 at 9:10 AM, Michael Paquier <michael.paqu...@gmail.com> wrote: > On Thu, Sep 11, 2014 at 5:21 AM, Heikki Linnakangas > <hlinnakan...@vmware.com> wrote: > > On 08/28/2014 10:10 AM, Michael Paquier wrote: > >> > >> + #synchronous_standby_num = -1 # number of standbys servers using sync > >> rep > > > > > > To be honest, that's a horrible name for the GUC. Back when synchronous > > replication was implemented, we had looong discussions on this feature. It > > was called "quorum commit" back then. I'd suggest using the "quorum" term in > > this patch, too, that's a fairly well-known term in distributed computing > > for this. > I am open to any suggestions. Then what about the following parameter names? > - synchronous_quorum_num > - synchronous_standby_quorum > - synchronous_standby_quorum_num > - synchronous_quorum_commit
or simply synchronous_standbys > > When synchronous replication was added, quorum was left out to keep things > > simple; the current feature set was the most we could all agree on to be > > useful. If you search the archives for "quorum commit" you'll see what I > > mean. There was a lot of confusion on what is possible and what is useful, > > but regarding this particular patch: people wanted to be able to describe > > more complicated scenarios. For example, imagine that you have a master and > > two standbys in one the primary data center, and two more standbys in a > > different data center. It should be possible to specify that you must get > > acknowledgment from at least on standby in both data centers. Maybe you > > could hack that by giving the standbys in the same data center the same > > name, but it gets ugly, and it still won't scale to even more complex > > scenarios. Won't this problem be handled if synchronous mode is supported in cascading replication? I am not sure about the feasibility of same, but I think the basic problem mentioned above can be addressed and may be others as well. With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
