Re: Quorum commit for multiple synchronous replication.

On Wed, Sep 21, 2016 at 11:22 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> On Wed, Sep 21, 2016 at 5:54 AM, Petr Jelinek <petr(at)2ndquadrant(dot)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.
>

As the release team announced, it's better to postpone changing the
syntax of existing s_s_name.
I still vote for changing behaviour of existing syntax 'k (n1, n2)' to
quorum commit.
That is,
1. 'First k (n1, n2, n3)' means that the master server waits for ACKs
from k standby servers whose name appear earlier in the list.
2. 'Any k (n1, n2, n3)' means that the master server waits for ACKs
from any k listed standby servers.
3. 'n1, n2, n3' is the same as #1 with k=1.
4. '(n1, n2, n3)' is the same as #2 with k=1.

Attached updated patch.

Regards,

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