Re: Support for N synchronous standby servers - take 2

On 06/26/2015 11:32 AM, Robert Haas wrote:
> I think your proposal is worth considering, but you would need to fill
> in a lot more details and explain how it works in detail, rather than
> just via a set of example function calls. The GUC-based syntax
> proposal covers cases like multi-level rules and, now, prioritization,
> and it's not clear how those would be reflected in what you propose.

So what I'm seeing from the current proposal is:

1. we have several defined synchronous sets
2. each set requires a quorum of k (defined per set)
3. within each set, replicas are arranged in priority order.

One thing which the proposal does not implement is *names* for
synchronous sets. I would also suggest that if I lose this battle and
we decide to go with a single stringy GUC, that we at least use JSON
instead of defining our out, proprietary, syntax?

Point 3. also seems kind of vaguely defined. Are we still relying on
the idea that multiple servers have the same application_name to make
them equal, and that anything else is a proritization? That is, if we have:

replica1: appname=group1
replica2: appname=group2
replica3: appname=group1
replica4: appname=group2
replica5: appname=group1
replica6: appname=group2

And the definition:

synchset: A
quorum: 2
members: [ group1, group2 ]

Then the desired behavior would be: we must get acks from at least 2
servers in group1, but if group1 isn't responding, then from group2?

What if *one* server in group1 responds? What do we do? Do we fail the
whole group and try for 2 out of 3 in group2? Or do we only need one in
group2? In which case, what prioritization is there? Who could
possibly use anything so complex?

I'm personally not convinced that quorum and prioritization are
compatible. I suggest instead that quorum and prioritization should be
exclusive alternatives, that is that a synch set should be either a
quorum set (with all members as equals) or a prioritization set (if rep1
fails, try rep2). I can imagine use cases for either mode, but not one
which would involve doing both together.

--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com