Re: Support for N synchronous standby servers - take 2 - Mailing list pgsql-hackers

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.

> anti-JSON:
> * more verbose
> * syntax is not backwards-compatible, we'd need a switch

This point is valid as well in the pro-JSON portion.

> * people will want to use line breaks, which we can't support

Yes, this is caused by the fact of using a GUC. For a simple formula
this seems fine to me though, that's what we have today for s_s_names
and using a formula is not much longer in character size than what we
have now.

> Re: group labels: I see a lot of value in being able to add names to
> quorum groups.  Think about how this will be represented in system
> views; it will be difficult to show sync status of any quorum group in
> any meaningful way if the group has no label, and any system-assigned
> label would change unpredictably from the user's perspective.
> To give a JSON example, let's take the case of needing to sync to two of
> the servers in either London or NC:
>
> '{ "remotes" : { "london_servers" : { "quorum" : 2, "servers" : [
> "london1", "london2", "london3" ] }, "nc_servers" : { "quorum" : 1,
> "servers" [ "nc1", "nc2" ] } }'

The JSON blob managing sync node information could contain additional
JSON objects that register a set of nodes as a given group. More
easily, you could use let's say the following structure to store the
blobs:
- pg_syncinfo/global, to store the root of the formula, that could use groups.
- pg_syncinfo/groups/$GROUP_NAME to store a set JSON blobs representing a group.

> The advantage of having these labels is that it becomes easy to
> represent statuses for them:
>
> sync_group      state           definition
> remotes         waiting         { "london_servers" : { "quorum" ...
> london_servers  synced          { "quorum" : 2, "servers" : ...
> nc_servers      waiting         { "quorum" : 1, "servers" [  ...
> Without labels, we force the DBA to track groups by raw definitions,
> which would be difficult.  Also, there's the question of what we do on
> reload with any statuses of synch groups which are currently in-process,
> if we don't have a stable key with which to identify groups.

Well, yes.

> The other grammar issue has to do with the nesting nature of quorums and
> priorities.  A theoretical user could want:
>
> * a priority list of quorum groups
> * a quorum group of priority lists
> * a quorum group of quorum groups
> * a priority list of quorum groups of quorum groups
> * a quorum group of quorum groups of priority lists
> ... etc.
>
> I don't really see any possible end to the possible permutations, which
> is why it would be good to establish some real use cases from now in
> order to figure out what we really want to support.  Absent that, my
> inclination is that we should implement the simplest possible thing
> (i.e. no nesting) for 9.5.

I am not sure I agree that this will simplify the work. Currently
s_s_names has already 1 level, and we want to append groups to each
element of it as well, meaning that we'll need at least 2 level of
nesting.
-- 
Michael