Re: Quorum commit for multiple synchronous replication.

From: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Petr Jelinek <petr(at)2ndquadrant(dot)com>, Vik Fearing <vik(at)2ndquadrant(dot)fr>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Josh Berkus <josh(at)agliodbs(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quorum commit for multiple synchronous replication.
Date: 2017-04-06 07:17:31
Message-ID: CAD21AoCcEsjt8t4TWW5oE3g=nu2oMFAiM47YeynpKJMoMdeEPA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 6, 2017 at 10:51 AM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Thu, Apr 06, 2017 at 12:48:56AM +0900, Fujii Masao wrote:
>> On Wed, Apr 5, 2017 at 3:45 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
>> > On Mon, Dec 19, 2016 at 09:49:58PM +0900, Fujii Masao wrote:
>> >> Regarding this feature, there are some loose ends. We should work on
>> >> and complete them until the release.
>> >>
>> >> (1)
>> >> Which synchronous replication method, priority or quorum, should be
>> >> chosen when neither FIRST nor ANY is specified in s_s_names? Right now,
>> >> a priority-based sync replication is chosen for keeping backward
>> >> compatibility. However some hackers argued to change this decision
>> >> so that a quorum commit is chosen because they think that most users
>> >> prefer to a quorum.
>> >>
>> >> (2)
>> >> There will be still many source comments and documentations that
>> >> we need to update, for example, in high-availability.sgml. We need to
>> >> check and update them throughly.
>> >>
>> >> (3)
>> >> The priority value is assigned to each standby listed in s_s_names
>> >> even in quorum commit though those priority values are not used at all.
>> >> Users can see those priority values in pg_stat_replication.
>> >> Isn't this confusing? If yes, it might be better to always assign 1 as
>> >> the priority, for example.
>> >
>> > [Action required within three days. This is a generic notification.]
>> >
>> > The above-described topic is currently a PostgreSQL 10 open item. Fujii,
>> > since you committed the patch believed to have created it, you own this open
>> > item. If some other commit is more relevant or if this does not belong as a
>> > v10 open item, please let us know. Otherwise, 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. Testers may
>> > discover new open items at any time, and I want to plan to get them all fixed
>> > well in advance of shipping v10. Consequently, I will appreciate your efforts
>> > toward speedy resolution. Thanks.
>> >
>> > [1] https://www.postgresql.org/message-id/20170404140717.GA2675809%40tornado.leadboat.com
>>
>> Thanks for the notice!
>>
>> Regarding the item (2), Sawada-san told me that he will work on it after
>> this CommitFest finishes. So we would receive the patch for the item from
>> him next week. If there will be no patch even after the end of next week
>> (i.e., April 14th), I will. Let's wait for Sawada-san's action at first.
>
> Sounds reasonable; I will look for your update on 14Apr or earlier.
>
>> The items (1) and (3) are not bugs. So I don't think that they need to be
>> resolved before the beta release. After the feature freeze, many users
>> will try and play with many new features including quorum-based syncrep.
>> Then if many of them complain about (1) and (3), we can change the code
>> at that timing. So we need more time that users can try the feature.
>
> I've moved (1) to a new section for things to revisit during beta. If someone
> feels strongly that the current behavior is Wrong and must change, speak up as
> soon as you reach that conclusion. Absent such arguments, the behavior won't
> change.
>
>> BTW, IMO (3) should be fixed so that pg_stat_replication reports NULL
>> as the priority if quorum-based sync rep is chosen. It's less confusing.
>
> Since you do want (3) to change, please own it like any other open item,
> including the mandatory status updates.

I agree to report NULL as the priority. I'll send a patch for this as well.

Regards,

--
Masahiko Sawada
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2017-04-06 07:32:08 Re: Implementation of SASLprep for SCRAM-SHA-256
Previous Message Masahiko Sawada 2017-04-06 07:15:33 Re: Interval for launching the table sync worker