Re: Support for N synchronous standby servers - take 2

On Thu, Oct 29, 2015 at 11:16 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Thu, Oct 22, 2015 at 12:47 AM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote:
>> On Tue, Oct 20, 2015 at 8:10 PM, Beena Emerson <memissemerson(at)gmail(dot)com> wrote:
>>>
>>> On Mon, Oct 19, 2015 at 8:47 PM, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
>>> wrote:
>>>>
>>>>
>>>> Hi,
>>>>
>>>> Attached patch is a rough patch which supports multi sync replication
>>>> by another approach I sent before.
>>>>
>>>> The new GUC parameters are:
>>>> * synchronous_standby_num, which specifies the number of standby
>>>> servers using sync rep. (default is 0)
>>>> * synchronous_replication_method, which specifies replication method;
>>>> priority or quorum. (default is priority)
>>>>
>>>> The behaviour of 'priority' and 'quorum' are same as what we've been
>>>> discussing.
>>>> But I write overview of these here again here.
>>>>
>>>> [Priority Method]
>>>> The standby server has each different priority, and the active standby
>>>> servers having the top N priroity are become sync standby server.
>>>> If synchronous_standby_names = '*', the all active standby server
>>>> would be sync standby server.
>>>> If you want to set up standby like 9.5 or before, you can set
>>>> synchronous_standby_num = 1.
>>>>
>>>
>>>
>>> I used the following setting with 2 servers A and D connected:
>>>
>>> synchronous_standby_names = 'A,B,C,D'
>>> synchronous_standby_num = 2
>>> synchronous_replication_method = 'priority'
>>>
>>> Though s_r_m = 'quorum' worked fine, changing it to 'priority' caused
>>> segmentation fault.
>>>
>>
>> Thank you for taking a look!
>> This patch is a tool for discussion, so I'm not going to fix this bug
>> until getting consensus.
>>
>> We are still under the discussion to find solution that can get consensus.
>> I felt that it's difficult to select from the two approaches within
>> this development cycle, and there would not be time to implement such
>> big feature even if we selected.
>> But this feature is obviously needed by many users.
>> So I'm considering more simple and extensible something solution, the
>> idea I posted is one of them.
>> The another worth considering approach is that just specifying the
>> number of sync standby. It also can cover the main use cases in
>> some-cases.
>
> Yes, it covers main and simple use case like "I want to have multiple
> synchronous replicas!". Even if we miss quorum commit at the first
> version, the feature is still very useful.

It can cover not only the case you mentioned but also main use case
Michael mentioned by setting same application_name.
And that first version patch is almost implemented, so just needs to
be reviewed.

I think that it would be good to implement the simple feature at the
first version, and then coordinate the design based on opinion and
feed backs from more user, use-case.

Regards,

--
Masahiko Sawada