Re: Quorum commit for multiple synchronous replication.
Masahiko Sawada <sawada.mshk@gmail.com>
From: Masahiko Sawada <sawada.mshk@gmail.com>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: Noah Misch <noah@leadboat.com>,
Michael Paquier <michael.paquier@gmail.com>, Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>,
Amit Kapila <amit.kapila16@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Petr Jelinek <petr@2ndquadrant.com>, Vik Fearing <vik@2ndquadrant.fr>, Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2017-04-25T00:22:59Z
Lists: pgsql-hackers
On Tue, Apr 25, 2017 at 12:56 AM, Fujii Masao <masao.fujii@gmail.com> wrote: > On Mon, Apr 24, 2017 at 9:02 AM, Noah Misch <noah@leadboat.com> wrote: >> On Thu, Apr 20, 2017 at 11:34:34PM -0700, Noah Misch wrote: >>> On Fri, Apr 21, 2017 at 01:20:05PM +0900, Masahiko Sawada wrote: >>> > On Fri, Apr 21, 2017 at 12:02 PM, Noah Misch <noah@leadboat.com> wrote: >>> > > On Wed, Apr 19, 2017 at 01:52:53PM +0900, Masahiko Sawada wrote: >>> > >> On Wed, Apr 19, 2017 at 12:34 PM, Noah Misch <noah@leadboat.com> wrote: >>> > >> > On Sun, Apr 16, 2017 at 07:25:28PM +0900, Fujii Masao wrote: >>> > >> >> As I told firstly this is not a bug. There are some proposals for better design >>> > >> >> of priority column in pg_stat_replication, but we've not reached the consensus >>> > >> >> yet. So I think that it's better to move this open item to "Design Decisions to >>> > >> >> Recheck Mid-Beta" section so that we can hear more opinions. >>> > >> > >>> > >> > I'm reading that some people want to report NULL priority, some people want to >>> > >> > report a constant 1 priority, and nobody wants the current behavior. Is that >>> > >> > an accurate summary? >>> > >> >>> > >> Yes, I think that's correct. >>> > > >>> > > Okay, but ... >>> > > >>> > >> FWIW the reason of current behavior is that it would be useful for the >>> > >> user who is willing to switch from ANY to FIRST. They can know which >>> > >> standbys will become sync or potential. >>> > > >>> > > ... does this mean you personally want to keep the current behavior? If not, >>> > > has some other person stated a wish to keep the current behavior? >>> > >>> > No, I want to change the current behavior. IMO it's better to set >>> > priority 1 to all standbys in quorum set. I guess there is no longer >>> > person who supports the current behavior. >>> >>> In that case, this open item is not eligible for section "Design Decisions to >>> Recheck Mid-Beta". That section is for items where we'll probably change >>> nothing, but we plan to recheck later just in case. Here, we expect to change >>> the behavior; the open question is which replacement behavior to prefer. >>> >>> Fujii, as the owner of this open item, you are responsible for moderating the >>> debate until there's adequate consensus to make a particular change or to keep >>> the current behavior after all. Please proceed to do that. Beta testers >>> deserve a UI they may like, not a UI you already plan to change later. >> >> Please observe the policy on open item ownership[1] and send a status update >> within three calendar days of this message. Include a date for your >> subsequent status update. > > Okay, so our consensus is to always set the priorities of sync standbys > to 1 in quorum-based syncrep case. Attached patch does this change. > Barrying any objection, I will commit this. +1 Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
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