On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs <si...@2ndquadrant.com> wrote:
> On 29 August 2016 at 14:52, Fujii Masao <masao.fu...@gmail.com> wrote:
>> On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek <p...@2ndquadrant.com> wrote:
>>> On 04/08/16 06:40, Masahiko Sawada wrote:
>>>>
>>>> On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier
>>>> <michael.paqu...@gmail.com> wrote:
>>>>>
>>>>> On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada <sawada.m...@gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> I was thinking that the syntax for quorum method would use '[ ... ]'
>>>>>> but it will be confused with '( ... )' priority method used.
>>>>>> 001 patch adds 'Any N ( ... )' style syntax but I know that we still
>>>>>> might need to discuss about better syntax, discussion is very welcome.
>>>>>> Attached draft patch, please give me feedback.
>>>>>
>>>>>
>>>>> I am +1 for using either "{}" or "[]" to define a quorum set, and -1
>>>>> for the addition of a keyword in front of the integer defining for how
>>>>> many nodes server need to wait for.
>>>>
>>>>
>>>> Thank you for reply.
>>>> "{}" or "[]" are not bad but because these are not intuitive, I
>>>> thought that it will be hard for uses to use different method for each
>>>> purpose.
>>>>
>>>
>>> I think the "any" keyword is more explicit and understandable, also closer
>>> to SQL. So I would be in favor of doing that.
>>
>> +1
>>
>> Also I like the following Simon's idea.
>>
>> https://www.postgresql.org/message-id/canp8+jlhfbvv_pw6grasnupw+bdk5dctu7gwpnap-+-zwvk...@mail.gmail.com
>> -----------------------
>> * first k (n1, n2, n3) – does the same as k (n1, n2, n3) does now
>> * any k (n1, n2, n3) – would release waiters as soon as we have the
>> responses from k out of N standbys. “any k” would be faster, so is
>> desirable for performance and resilience
>> -----------------------
>
> +1
>
> "synchronous_method" -> "synchronization_method"Thanks, will fix. > I'm concerned about the performance of this code. Can we work out a > way of measuring it, so we can judge how successful we are at > releasing waiters quickly? Thanks I will measure the performance effect of this code. I'm expecting that performances are, 'first 1 (n1, n2)' > 'any 1(n1, n2)' > 'first 2(n1, n2)' 'first 1 (n1, n2)' will be highest throughput. > For 9.6 we implemented something that allows the DBA to define how > slow programs are. Previously, since 9.1 this was something specified > on the application side. I would like to put it back that way, so we > end up with a parameter on client e.g. commit_quorum = k. Forget the > exact parameters/user API for now, but I'd like to allow the code to > work with user defined settings. Thanks. I see. The parameter on client should effect for priority method as well. And similar to synchronous_commit, the client can specify the how much standbys the master waits to commit for according to synchronization method, even if s_s_names is defined. Regards, -- Masahiko Sawada NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
