Re: Support for N synchronous standby servers - take 2

On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson <memissemerson@gmail.com> wrote:
> Simon Riggs wrote:
>
>> The choice between formats is not
>> solely predicated on whether we have multi-line support.
>
>> I still think writing down some actual use cases would help bring the
>> discussion to a conclusion. Inventing a general facility is hard without
>> some clear goals about what we need to support.
>
> We need to at least support the following:
> - Grouping: Specify of standbys along with the minimum number of commits
> required from the group.
> - Group Type: Groups can either be priority or quorum group.

As far as I understood at the lowest level a group is just an alias
for a list of nodes, quorum or priority are properties that can be
applied to a group of nodes when this group is used in the expression
to define what means synchronous commit.

> - Group names: to simplify status reporting
> - Nesting: At least 2 levels of nesting

If I am following correctly, at the first level there is the
definition of the top level objects, like groups and sync expression.

> Using JSON, sync rep parameter to replicate in 2 different clusters could be
> written as:
>
>    {"remotes":
>         {"quorum": 2,
>          "servers": [{"london":
>             {"priority": 2,
>              "servers": ["lndn1", "lndn2", "lndn3"]
>             }}
>             ,
>               {"nyc":
>             {"priority": 1,
>              "servers": ["ny1", "ny2"]
>             }}
>           ]
>         }
>     }
> The same parameter in the new language (as suggested above) could be written
> as:
>  'remotes: 2(london: 1[lndn1, lndn2, lndn3], nyc: 1[ny1, ny2])'

OK, there is a typo. That's actually 2(london: 2[lndn1, lndn2, lndn3],
nyc: 1[ny1, ny2]) in your grammar. Honestly, if we want group aliases,
I think that JSON makes the most sense. One of the advantage of a
group is that you can use it in several places in the blob and set
different properties into it, hence we should be able to define a
group out of the sync expression.

Hence I would think that something like that makes more sense:
{       "sync_standby_names":       {               "quorum":2,               "nodes":               [
    {"priority":1,"group":"cluster1"},                       {"quorum":2,"nodes":["node1","node2","node3"]}
 ]       },       "groups":       {               "cluster1":["node11","node12","node13"],
"cluster2":["node21","node22","node23"]      }
 
}

> Also, I was thinking the name of the main group could be optional.
> Internally, it can be given the name 'default group' or 'main group' for
> status reporting.
>
> The above could also be written as:
>  '2(london: 2[lndn1, lndn2, lndn3], nyc: 1[ny1, ny2])'
>
> backward compatible:
> In JSON, while validating we may have to check if it starts with '{' to go

Something worth noticing, application_name can begin with "{".

> for JSON parsing else proceed with the current method.

> A,B,C => 1[A,B,C]. This can be added in the new parser code.

This makes sense. We could do the same for JSON-based format as well
by reusing the in-memory structure used to deparse the blob when the
former grammar is used as well.
-- 
Michael