Re: Support for N synchronous standby servers - take 2

On 7 July 2015 at 07:03, Michael Paquier <michael(dot)paquier(at)gmail(dot)com> wrote:

> On Tue, Jul 7, 2015 at 2:19 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> > On 07/06/2015 09:56 PM, Michael Paquier wrote:
> >> On Tue, Jul 7, 2015 at 12:51 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> >>> On 07/06/2015 06:40 PM, Michael Paquier wrote:
> >>>> On Tue, Jul 7, 2015 at 2:56 AM, Josh Berkus <josh(at)agliodbs(dot)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