<p dir="ltr">On Jul 14, 2015 7:15 AM, "Fujii Masao" <<a
href="mailto:masao.fujii@gmail.com">masao.fujii@gmail.com</a>>wrote:<br /> ><br /> > On Tue, Jul 14, 2015 at
9:00AM, Michael Paquier<br /> > <<a href="mailto:michael.paquier@gmail.com">michael.paquier@gmail.com</a>>
wrote:<br/> > > On Mon, Jul 13, 2015 at 10:34 PM, Fujii Masao wrote:<br /> > >> On Fri, Jul 10, 2015 at
10:06PM, Beena Emerson wrote:<br /> > >>> On Tue, Jul 7, 2015 at 2:19 PM, Michael Paquier wrote:<br /> >
>>><br/> > >>>> Something like pg_syncinfo/ coupled with a LW lock, we already do<br /> >
>>>>something similar for replication slots with pg_replslot/.<br /> > >>><br /> >
>>>I was trying to figure out how the JSON metadata can be used.<br /> > >>> It would have to be
setusing a given set of functions.<br /> > >><br /> > >> So we can use only such a set of functions
toconfigure synch rep?<br /> > >> I don't like that idea. Because it prevents us from configuring that<br />
>>> while the server is not running.<br /> > ><br /> > > If you store a json blob in a set of
filesof PGDATA you could update<br /> > > them manually there as well. That's perhaps re-inventing the wheel<br
/>> > with what is available with GUCs though.<br /> ><br /> > Why don't we just use GUC? If the quorum
settingis not so complicated<br /> > in real scenario, GUC seems enough for that.<p dir="ltr">I agree GUC would be
enough.<br/> We could also name groups in it.<p dir="ltr">I am thinking of the following format similar to JSON<p
dir="ltr"><group_name>:<count>(<list>)<br /> Use of square brackets for priority.<p dir="ltr">Ex:<br
/>s_s_names = 'remotes: 2 (london: 1 [lndn1, lndn2], nyc: 1[nyc1,nyc2])'<br /><p dir="ltr">Regards,<p dir="ltr">Beena
Emerson<br />