On 7 July 2015 at 07:03, Michael Paquier <michael.paqu...@gmail.com> wrote:
> On Tue, Jul 7, 2015 at 2:19 PM, Josh Berkus <j...@agliodbs.com> wrote: > > On 07/06/2015 09:56 PM, Michael Paquier wrote: > >> On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus <j...@agliodbs.com> wrote: > >>> On 07/06/2015 06:40 PM, Michael Paquier wrote: > >>>> On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus <j...@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/ <http://www.2ndquadrant.com/> PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
