On Tue, Aug 4, 2015 at 8:37 PM, Beena Emerson <memissemerson@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
