Re: Quorum commit for multiple synchronous replication.

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

> 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