Re: Quorum commit for multiple synchronous replication.

Josh Berkus <josh@agliodbs.com>

From: Josh Berkus <josh@agliodbs.com>
To: Fujii Masao <masao.fujii@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>, Michael Paquier <michael.paquier@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-09-06T19:03:41Z
Lists: pgsql-hackers
On 08/29/2016 06:52 AM, Fujii Masao wrote:
> Also I like the following Simon's idea.
> 
> https://www.postgresql.org/message-id/CANP8+jLHfBVv_pW6grASNUpW+bdk5DcTu7GWpNAP-+-ZWvKT6w@mail.gmail.com
> -----------------------
> * first k (n1, n2, n3) – does the same as k (n1, n2, n3) does now
> * any k (n1, n2, n3) – would release waiters as soon as we have the
> responses from k out of N standbys. “any k” would be faster, so is
> desirable for performance and resilience

What are we going to do for backwards compatibility, here?

So, here's the dilemma:

If we want to keep backwards compatibility with 9.6, then:

"k (n1, n2, n3)" == "first k (n1, n2, n3)"

However, "first k" is not what most users will want, most of the time;
users of version 13, years from now, will be getting constantly confused
by "first k" behavior when they wanted quorum.  So the sensible default
would be:

"k (n1, n2, n3)" == "any k (n1, n2, n3)"

... however, that will break backwards compatibility.  Thoughts?

My $0.02 is that we break backwards compat somehow and document the heck
out of it.

-- 
--
Josh Berkus
Red Hat OSAS
(any opinions are my own)


Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →
  1. Set the priorities of all quorum synchronous standbys to 1.

  2. Improve documentation and comment for quorum-based sync replication.