Re: Quorum commit for multiple synchronous replication.

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Noah Misch <noah(at)leadboat(dot)com>
Cc: Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Masahiko Sawada <sawada(dot)mshk(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-05 15:48:56
Message-ID: CAHGQGwEMJgvWLsQv0FAfZ6wHSwG+ijTc3s46g6SZWiAvxFz6GQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

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.

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.

Regards,

--
Fujii Masao

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2017-04-05 15:49:58 Re: inconsistent page found on STANDBY server
Previous Message Peter Eisentraut 2017-04-05 15:33:51 Re: Logical Replication and Character encoding