On Fri, Jul 10, 2015 at 10:06 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Hello, > > Tue, Jul 7, 2015 at 02:56 AM, Josh Berkus wrote: >> pro-JSON: >> >> * standard syntax which is recognizable to sysadmins and devops. >> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make >> additions/deletions from the synch rep config. >> * can add group labels (see below) > > Adding group labels do have a lot of values but as Amit has pointed out, > with little modification, they can be included in GUC as well. It will not > make it any more complex. > > 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. Right? > I am sorry this question is very basic. > > The functions could be something like: > 1. pg_add_synch_set(set_name NAME, quorum INT, is_priority bool, set_members > VARIADIC) > > This will be used to add a sync set. The set_members can be individual > elements of another set name. The parameter is_priority is used to decide > whether the set is priority (true) set or quorum (false). This function call > will create a folder pg_syncinfo/groups/$NAME and store the json blob? > > The root group would be automatically sset by finding the group which is not > included in other groups? or can be set by another function? > > 2. pg_modify_sync_set(set_name NAME, quorum INT, is_priority bool, > set_members VARIADIC) > > This will update the pg_syncinfo/groups/$NAME to store the new values. > > 3. pg_drop_synch_set(set_name NAME) > > This will update the pg_syncinfo/groups/$NAME folder. Also all the groups > which included this would be updated? > > 4. pg_show_synch_set() > > this will display the current sync setting in json format. > > Am I missing something? > > Is JSON being preferred because it would be ALTER SYSTEM friendly and in a > format already known to users? > > In a real-life scenario, at most how many groups and nesting would be > expected? >
I might missing something but, these functions will generate WAL? If they does, we will face the situation where we need to wait forever, Fujii-san pointed out. Regards, -- Masahiko Sawada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers