From: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | sawada(dot)mshk(at)gmail(dot)com |
Cc: | masao(dot)fujii(at)gmail(dot)com, memissemerson(at)gmail(dot)com, josh(at)agliodbs(dot)com, robertmhaas(at)gmail(dot)com, amit(dot)kapila16(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Support for N synchronous standby servers - take 2 |
Date: | 2015-11-17 10:40:10 |
Message-ID: | 20151117.194010.17198448.horiguchi.kyotaro@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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?
> So, how about the adding just s_r_method parameter and the number of
> required ACK is represented in the leading of s_r_method?
> For example, the following setting is same as above.
>
> synchronous_replication_method = "2-priority"
> synchronous_standby_names = "mercury, venus, earth, mars, jupiter"
I *feel* it is the same or worse as having the third parameter
s_s_num as your previous design.
> In quorum method, we can set;
> synchronous_replication_method = "2-quorum"
> synchronous_standby_names = "mercury, venus, earth, mars, jupiter"
>
> Thought?
regards,
--
Kyotaro Horiguchi
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Thom Brown | 2015-11-17 10:41:22 | Re: Freeze avoidance of very large table. |
Previous Message | Masahiko Sawada | 2015-11-17 10:29:48 | Re: Freeze avoidance of very large table. |