On Tue, Jul 7, 2015 at 2:19 PM, Josh Berkus <josh@agliodbs.com> wrote: > On 07/06/2015 09:56 PM, Michael Paquier wrote: >> On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus <josh@agliodbs.com> wrote: >>> On 07/06/2015 06:40 PM, Michael Paquier wrote: >>>> On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus <josh@agliodbs.com> wrote: >>>>> pro-JSON: >>>>> >>>>> * standard syntax which is recognizable to sysadmins and devops. >>>>> * can use JSON/JSONB functions with ALTER SYSTEM SET to easily make >>>>> additions/deletions from the synch rep config. >>>>> * can add group labels (see below) >>>> >>>> If we go this way, I think that managing a JSON blob with a GUC >>>> parameter is crazy, this is way longer in character size than a simple >>>> formula because of the key names. Hence, this JSON blob should be in a >>>> separate place than postgresql.conf not within the catalog tables, >>>> manageable using an SQL interface, and reloaded in backends using >>>> SIGHUP. >>> >>> I'm not following this at all. What are you saying here? >> >> A JSON string is longer in terms of number of characters than a >> formula because it contains key names, and those key names are usually >> repeated several times, making it harder to read in a configuration >> file. So what I am saying that that we do not save it as a GUC, but as >> a separate metadata that can be accessed with a set of SQL functions >> to manipulate it. > > Where, though? Someone already pointed out the issues with storing it > in a system catalog, and adding an additional .conf file with a > different format is too horrible to contemplate.
Something like pg_syncinfo/ coupled with a LW lock, we already do something similar for replication slots with pg_replslot/.
-1 to pg_syncinfo/
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.
--
Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services