On Tue, Aug 4, 2015 at 8:37 PM, Beena Emerson <memissemer...@gmail.com> wrote: > Robert Haas wrote: >>Maybe shoehorning this into the GUC mechanism is the wrong thing, and >>what we really need is a new config file for this. The information >>we're proposing to store seems complex enough to justify that. >> > > I think the consensus is that JSON is better.
I guess so as well. Thanks for brainstorming the whole thread in a single post. > And using a new file with multi line support would be good. This file just contains a JSON blob, hence we just need to fetch its content entirely and then let the server parse it using the existing facilities. > Name of the file: how about pg_syncinfo.conf? > Backward compatibility: synchronous_standby_names will be supported. > synchronous_standby_names='pg_syncinfo' indicates use of new file. This strengthens the fact that parsing is done at SIGHUP, so that sounds fine to me. We may still find out an application_name that uses pg_syncinfo but well, that's unlikely to happen... > JSON format: > It would contain 2 main keys: "sync_info" and "groups" > The "sync_info" would consist of "quorum"/"priority" with the count and > "nodes"/"group" with the group name or node list. > The optional "groups" key would list out all the "group" mentioned within > "sync_info" along with the node list. > > [...] > > Thoughts? Yes, I think that's the idea. I would let a couple of days to let people time to give their opinion and objections regarding this approach though. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers