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 →
-
Set the priorities of all quorum synchronous standbys to 1.
- 346199dcab4c 10.0 landed
-
Improve documentation and comment for quorum-based sync replication.
- a790ed9f69ef 10.0 landed