Re: Quorum commit for multiple synchronous replication.

Поиск
Список
Период
Сортировка
От Simon Riggs
Тема Re: Quorum commit for multiple synchronous replication.
Дата
Msg-id CANP8+j+CpE+7BLf8b+JFemawjE75pzxL4ZjHXiMqzTubC=gLLw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Quorum commit for multiple synchronous replication.  (Fujii Masao <masao.fujii@gmail.com>)
Ответы Re: Quorum commit for multiple synchronous replication.  (Masahiko Sawada <sawada.mshk@gmail.com>)
Список pgsql-hackers
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"

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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Proposal for changes to recovery.conf API
Следующее
От: David Steele
Дата:
Сообщение: Re: Proposal for changes to recovery.conf API