Re: Support for N synchronous standby servers - take 2

On Jul 14, 2015 7:15 AM, "Fujii Masao" <masao(dot)fujii(at)gmail(dot)com> wrote:
>
> On Tue, Jul 14, 2015 at 9:00 AM, Michael Paquier
> <michael(dot)paquier(at)gmail(dot)com> wrote:
> > On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote:
> >> On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson wrote:
> >>> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote:
> >>>
> >>>> Something like pg_syncinfo/ coupled with a LW lock, we already do
> >>>> something similar for replication slots with pg_replslot/.
> >>>
> >>> I was trying to figure out how the JSON metadata can be used.
> >>> It would have to be set using a given set of functions.
> >>
> >> So we can use only such a set of functions to configure synch rep?
> >> I don't like that idea. Because it prevents us from configuring that
> >> while the server is not running.
> >
> > If you store a json blob in a set of files of PGDATA you could update
> > them manually there as well. That's perhaps re-inventing the wheel
> > with what is available with GUCs though.
>
> Why don't we just use GUC? If the quorum setting is not so complicated
> in real scenario, GUC seems enough for that.

I agree GUC would be enough.
We could also name groups in it.

I am thinking of the following format similar to JSON

<group_name>:<count> (<list>)
Use of square brackets for priority.

Ex:
s_s_names = 'remotes: 2 (london: 1 [lndn1, lndn2], nyc: 1[nyc1,nyc2])'

Regards,

Beena Emerson