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-11 17:36:18
Message-ID: CAD21AoDsQDD1=+9N+9O674VwA8ym97kV65EkWo11SBuSA4jKKg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 6, 2017 at 4:17 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
> 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,
>

Attached two draft patches. The one makes pg_stat_replication.sync
priority report NULL if in quorum-based sync replication. To prevent
extra change I don't change so far the code of setting standby
priority. The another one improves the comment and documentation. If
there is more thing what we need to mention in documentation please
give me feedback.

Regards,

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

Attachment Content-Type Size
report_null_as_sync_priority.patch application/octet-stream 2.4 KB
quorum_repl_doc_improve.patch application/octet-stream 5.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-11 17:36:44 my open items vs. my vacation
Previous Message Alexander Kuzmenkov 2017-04-11 17:24:56 index-only count(*) for indexes supporting bitmap scans