Re: Support for N synchronous standby servers - take 2

On Wed, Oct 14, 2015 at 3:16 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> On 10/13/2015 11:02 AM, Masahiko Sawada wrote:
>> I thought that this feature for postgresql should be simple at first
>> implementation.
>> It would be good even if there are some restriction such as the
>> nesting level, the group setting.
>> The another new approach that I came up with is,
>> * Add new parameter synchronous_replication_method (say s_r_method)
>> which can have two names: 'priority', 'quorum'
>> * If s_r_method = 'priority', the value of s_s_names (e.g. 'n1,n2,n3')
>> is handled using priority. It's same as '[n1,n2,n3]' in dedicated
>> laguage.
>> * If s_r_method = 'quorum', the value of s_s_names is handled using
>> quorum commit, It's same as '(n1,n2,n3)' in dedicated language.
>
> Well, the first question is: can you implement both of these things for
> 9.6, realistically?
> If you can implement them, then we can argue about
> configuration format later. It's even possible that the nature of your
> implementation will enforce a particular syntax.
>
> For example, if your implementation requires sync groups to be named,
> then we have to include group names in the syntax. If you can't
> implement nesting in the near future, there's no reason to have a syntax
> for it.

Yes, I can implement both without nesting.
The draft patch of replication using priority is already implemented
by Michael, so I need to implement simple quorum commit logic and
merge them.

>> * Setting of synchronous_standby_names is same as today. That is, the
>> storing the nesting value is not supported.
>> * If we want to support more complex syntax like what we are
>> discussing, we can add the new value to s_r_method, for example
>> 'complex', 'json'.
>
> I think having two different syntaxes is a bad idea. I'd rather have a
> wholly proprietary configuration markup than deal with two alternate ones.
>

I agree, we should choice either.

Regards,

--
Masahiko Sawada