Re: Quorum commit for multiple synchronous replication. - Mailing list pgsql-hackers

From Petr Jelinek
Subject Re: Quorum commit for multiple synchronous replication.
Date
Msg-id a5c94de1-b962-33ef-193f-93c48ea8ea08@2ndquadrant.com
Whole thread Raw
In response to Re: Quorum commit for multiple synchronous replication.  (Noah Misch <noah@leadboat.com>)
List pgsql-hackers
On 06/04/17 03:51, Noah Misch 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@leadboat.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.
> 

I was one of the people who said in original thread that I think the
default behavior should change to quorum and I am still of that opinion.

--  Petr Jelinek                  http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training &
Services



pgsql-hackers by date:

Previous
From: Kyotaro HORIGUCHI
Date:
Subject: Re: Interval for launching the table sync worker
Next
From: David Rowley
Date:
Subject: Re: [COMMITTERS] pgsql: Collect and use multi-columndependency stats