Re: Support for N synchronous standby servers - take 2

On Tue, Nov 17, 2015 at 7:52 PM, Kyotaro HORIGUCHI
<horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote:
> Oops.
>
> At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> wrote in <20151117(dot)194010(dot)17198448(dot)horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
>> Hello,
>>
>> At Tue, 17 Nov 2015 18:13:11 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in <CAD21AoC=AN+DKYNwsJp6COZ-6qmHXxuENxVPisxgPXcuXmPEvw(at)mail(dot)gmail(dot)com>
>> > >> One question is that what is different between the leading "n" in
>> > >> s_s_names and the leading "n" of "n-priority"?
>> > >
>> > > Ah. Sorry for the ambiguous description. 'n' in s_s_names
>> > > representing an arbitrary integer number and that in "n-priority"
>> > > is literally an "n", meaning "a format with any number of
>> > > priority hosts" as a whole. As an instance,
>> > >
>> > > synchronous_replication_method = "n-priority"
>> > > synchronous_standby_names = "2, mercury, venus, earth, mars, jupiter"
>> > >
>> > > I added "n-" of "n-priority" to distinguish with "1-priority" so
>> > > if we won't provide "1-priority" for backward compatibility,
>> > > "priority" would be enough to represent the type.
>> > >
>> > > By the way, s_r_method is not essentially necessary but it would
>> > > be important to avoid complexity of autodetection of formats
>> > > including currently undefined ones.
>> >
>> > Than you for your explanation, I understood that.
>> >
>> > It means that the format of s_s_names will be changed, which would be not good.
>>
>> I believe that the format of definition of "replication set"(?)
>> is not fixed and it would be more complex format to support
>> nested definition. This should be in very different format from
>> the current simple list of names. This is a selection among three
>> or possiblly more disigns in order to be tolerable for future
>> changes, I suppose.
>>
>> 1. Additional formats of definition in future will be stored in
>> elsewhere of s_s_names.
>>
>> 2. Additional format will be stored in s_s_names, the format will
>> be automatically detected.
>>
>> 3. (ditto), the format is designated by s_r_method.
>>
>> 4. Any other way?
>>
>> I choosed the third way. What do you think about future expansion
>> of the format?
>>

I agree with #3 way and the s_s_name format you suggested.
I think that It's extensible and is tolerable for future changes.
I'm going to implement the patch based on this idea if other hackers
agree with this design.

Regards,

--
Masahiko Sawada