On Wed, Sep 21, 2016 at 11:22 PM, Robert Haas <robertmh...@gmail.com> wrote:
> On Wed, Sep 21, 2016 at 5:54 AM, Petr Jelinek <p...@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=4njgmmgiagvcs...@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.


Masahiko Sawada
NTT Open Source Software Center

Attachment: quorum_commit_v3.patch
Description: Binary data

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to