Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: Support for N synchronous standby servers - take 2
Date
Msg-id 20151117.195232.168237896.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: Support for N synchronous standby servers - take 2  (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>)
Responses Re: Support for N synchronous standby servers - take 2  (Masahiko Sawada <sawada.mshk@gmail.com>)
List pgsql-hackers
Oops. 

At Tue, 17 Nov 2015 19:40:10 +0900 (Tokyo Standard Time), Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> wrote in
<20151117.194010.17198448.horiguchi.kyotaro@lab.ntt.co.jp>
> Hello,
> 
> At Tue, 17 Nov 2015 18:13:11 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in
<CAD21AoC=AN+DKYNwsJp6COZ-6qmHXxuENxVPisxgPXcuXmPEvw@mail.gmail.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.

I feel it is the same or worse *than* 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




pgsql-hackers by date:

Previous
From: Thom Brown
Date:
Subject: Re: Freeze avoidance of very large table.
Next
From: Ildus Kurbangaliev
Date:
Subject: Re: [PATCH] Refactoring of LWLock tranches