Re: Support for N synchronous standby servers - take 2

On Tue, Feb 2, 2016 at 8:48 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> So you disagree with only third version that I proposed, i.e.,
> adding some hooks for sync replication? If yes and you're OK
> with the first and second versions, ISTM that we almost reached
> consensus on the direction of multiple sync replication feature.
> The first version can cover "one local and one remote sync standbys" case,
> and the second can cover "one local and at least one from several remote
> standbys" case. I'm thinking to focus on the first version now,
> and then we can work on the second to support the quorum commit

Well, I think the only hard part of the third problem is deciding on
what syntax to use. It seems like a waste of time to me to go to a
bunch of trouble to implement #1 and #2 using one syntax and then have
to invent a whole new syntax for #3. Seriously, this isn't that hard:
it's not a technical problem. It's just that we've got a bunch of
people who can't agree on what syntax to use. IMO, you should just
pick something. You're presumably the committer for this patch, and I
think you should just decide which of the 47,123 things proposed so
far is best and insist on that. I trust that you will make a good
decision even if it's different than the decision that I would have
made.

Now, if it's easier to implement a subset of that syntax first and
then extend it later, fine. But it makes no sense to me to implement
the easy cases without having some idea of how you're go to extend
that to the hard cases. Then you'll just end up with a mishmash.
Pick something that can be extended to handle all of the plausible
cases, whether it's a mini-language or a JSON blob or a
pg_hba.conf-type file or some other crazy thing that you invent, and
just do it and be done with it. We've wasted far too much time trying
to reach consensus on this: it's time for you to exercise your vast
dictatorial power.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company