Re: Support for N synchronous standby servers - take 2

On Sun, Jan 31, 2016 at 8:58 PM, Michael Paquier
<michael.paquier@gmail.com> wrote:
> On Sun, Jan 31, 2016 at 5:28 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>> On Sun, Jan 31, 2016 at 5:18 PM, Michael Paquier
>> <michael.paquier@gmail.com> wrote:
>>> On Sun, Jan 31, 2016 at 5:08 PM, Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>>>> On Sun, Jan 31, 2016 at 1:17 PM, Michael Paquier
>>>> <michael.paquier@gmail.com> wrote:
>>>>> On Thu, Jan 28, 2016 at 10:10 PM, Masahiko Sawada wrote:
>>>>>> By the discussions so far, I'm planning to have several replication
>>>>>> methods such as 'quorum', 'complex' in the feature, and the each
>>>>>> replication method specifies the syntax of s_s_names.
>>>>>> It means that s_s_names could have the number of sync standbys like
>>>>>> what current patch does.
>>>>>
>>>>> What if the application_name of a standby node has the format of an integer?
>>>>
>>>> Even if the standby has an integer as application_name, we can set
>>>> s_s_names like '2,1,2,3'.
>>>> The leading '2' is always handled as the number of sync standbys when
>>>> s_r_method = 'priority'.
>>>
>>> Hm. I agree with Fujii-san here, having the number of sync standbys
>>> defined in a parameter that should have a list of names is a bit
>>> confusing. I'd rather have a separate GUC, which brings us back to one
>>> of the first patches that I came up with, and a couple of people,
>>> including Josh were not happy with that because this did not support
>>> real quorum. Perhaps the final answer would be really to get a set of
>>> hooks, and a contrib module making use of that.
>>
>> Yeah, I agree with having set of hooks, and postgres core has simple
>> multi sync replication mechanism like you suggested at first version.
>
> If there are hooks, I don't think that we should really bother about
> having in core anything more complicated than what we have now. The
> trick will be to come up with a hook design modular enough to support
> the kind of configurations mentioned on this thread. Roughly perhaps a
> refactoring of the syncrep code so as it is possible to wait for
> multiple targets some of them being optional,, one modular way in
> pg_stat_get_wal_senders to represent the status of a node to user, and
> another hook to return to decide which are the nodes to wait for. Some
> of the nodes being waited for may be based on conditions for quorum
> support. That's a hard problem to do that in a flexible enough way.

Hm, I think not-nested quorum and priority are not complicated, and we
should support at least both or either simple method in core of
postgres.
More complicated method like using json-style, or dedicated language
would be supported by external module.

Regards,

--
Masahiko Sawada