On Thu, Sep 11, 2014 at 9:10 AM, Michael Paquier <
michael.paquier@gmail.com> wrote:
> On Thu, Sep 11, 2014 at 5:21 AM, Heikki Linnakangas
> <
hlinnakangas@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.