Re: Quorum commit for multiple synchronous replication.

On Wed, Sep 7, 2016 at 12:47 AM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> On Tue, Sep 6, 2016 at 11:08 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> On 29 August 2016 at 14:52, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> On Sat, Aug 6, 2016 at 6:36 PM, Petr Jelinek <petr@2ndquadrant.com> wrote:
>>>> On 04/08/16 06:40, Masahiko Sawada wrote:
>>>>>
>>>>> On Wed, Aug 3, 2016 at 3:05 PM, Michael Paquier
>>>>> <michael.paquier@gmail.com> wrote:
>>>>>>
>>>>>> On Wed, Aug 3, 2016 at 2:52 PM, Masahiko Sawada <sawada.mshk@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-+-ZWvKT6w@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.
>

Sorry, that's wrong.
'any 1(n1, n2)' will be highest throughput or same as 'first 1(n1, n2)'.

>> 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

Regards,

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