On 15 July 2015 at 10:03, Michael Paquier <michael.paqu...@gmail.com> wrote:
> OK, so this is leading us to the following points:
> - Use a JSON object to define the quorum/priority groups for the sync
> state.
> - Store it as a GUC, and use the check hook to validate its format,
> which is what we have now with s_s_names
> - Rely on SIGHUP to maintain an in-memory image of the quorum/priority
> sync state
> - Have the possibility to define group labels in this JSON blob, and
> be able to use those labels in a quorum or priority sync definition.
>
+1
> - For backward-compatibility, use for example s_s_names = 'json' to
> switch to the new system.
>
Seems easy enough to check to see if it is has a leading { and then treat
it as if it is an attempt to use JSON (which may fail), otherwise use the
old syntax.
> Also, as a first step of the implementation, do we actually need a set
> of functions to manipulate the JSON blob. I mean, we could perhaps
> have them in contrib/ but they do not seem mandatory as long as we
> document correctly how to document a label group and define a quorum
> or priority group, no?
>
Agreed, no specific functions needed to manipulate this field.
If we lack the means to manipulate JSON in SQL that can be solved outside
of the scope of this patch, because its just JSON.
--
Simon Riggs http://www.2ndQuadrant.com/
<http://www.2ndquadrant.com/>
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
