Re: Quorum commit for multiple synchronous replication.
От | Josh Berkus |
---|---|
Тема | Re: Quorum commit for multiple synchronous replication. |
Дата | |
Msg-id | 16aeb57d-b53e-07f2-41e9-22da0f50f6df@agliodbs.com обсуждение исходный текст |
Ответ на | Quorum commit for multiple synchronous replication. (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: Quorum commit for multiple synchronous replication.
|
Список | 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)
В списке pgsql-hackers по дате отправления: