On Jul 14, 2015 7:15 AM, "Fujii Masao" <masao.fu...@gmail.com> wrote: > > On Tue, Jul 14, 2015 at 9:00 AM, Michael Paquier > <michael.paqu...@gmail.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
