Horton
Menu

Re: Quorum commit for multiple synchronous replication.

Robert Haas <robertmhaas@gmail.com>

View thread
From: Robert Haas <robertmhaas@gmail.com>
To: Petr Jelinek <petr@2ndquadrant.com>
Cc: Vik Fearing <vik@2ndquadrant.fr>, Michael Paquier <michael.paquier@gmail.com>, Masahiko Sawada <sawada.mshk@gmail.com>, Simon Riggs <simon@2ndquadrant.com>, Josh Berkus <josh@agliodbs.com>, Fujii Masao <masao.fujii@gmail.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2016-09-21T14:22:37Z
Lists: pgsql-hackers 
On Wed, Sep 21, 2016 at 5:54 AM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>>> Reading again the thread, it seems that my previous post [1] was a bit
>>> misunderstood. My position is to not introduce any new behavior
>>> changes in 9.6, so we could just make the FIRST NUM grammar equivalent
>>> to NUM.
>>>
>>> [1]: https://www.postgresql.org/message-id/CAB7nPqRDvJn18e54ccNpOP1A2_iUN6-iU=4nJgmMgiAgvcSDKA@mail.gmail.com
>>
>> I misunderstood your intent, then.  But I still stand by what I did
>> understand, namely that 'k (...)'  should mean 'any k (...)'.  It's much
>> more natural than having it mean 'first k (...)' and I also think it
>> will be more frequent in practice.
>>
>
> I think so as well.

Well, I agree, but I think making behavior changes after rc1 is a
non-starter.  It's better to live with the incompatibility than to
change the behavior so close to release.  At least, that's my
position.  Getting the release out on time with a minimal bug count is
more important to me than a minor incompatibility in the meaning of
one GUC.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Set the priorities of all quorum synchronous standbys to 1.

  2. Improve documentation and comment for quorum-based sync replication.