On Wed, Jul 15, 2015 at 3:53 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
> pg_replslot has persistent state. We are discussing permanent configuration
> data for which I don't see the need to create an additional parallel
> infrastructure just to store a string given stated objection that the string
> is fairly long. AFAICS its not even that long.
>
> ...
>
> JSON seems the most sensible format for the string. Inventing a new one
> doesn't make sense. Most important for me is the ability to programmatically
> manipulate/edit the config string, which would be harder with a new custom
> format.
>
> ...
>
> Group labels are essential.
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.
- For backward-compatibility, use for example s_s_names = 'json' to
switch to the new system.
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?
--
Michael