On Wed, Jul 15, 2015 at 3:53 PM, Simon Riggs <si...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
