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. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
quorum_commit_v3.patch
Description: Binary data
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
