Re: Quorum commit for multiple synchronous replication.

From: Simon Riggs <simon(at)2ndquadrant(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Petr Jelinek <petr(at)2ndquadrant(dot)com>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Quorum commit for multiple synchronous replication.
Date: 2016-09-06 14:08:56
Message-ID: CANP8+j+CpE+7BLf8b+JFemawjE75pzxL4ZjHXiMqzTubC=gLLw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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"

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

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.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2016-09-06 14:11:51 Re: Proposal for changes to recovery.conf API
Previous Message Michael Paquier 2016-09-06 13:38:43 Re: Proposal for changes to recovery.conf API