On Tue, Jul 21, 2015 at 3:50 PM, Michael Paquier
<michael.paqu...@gmail.com> wrote:
> On Mon, Jul 20, 2015 at 9:59 PM, Beena Emerson <memissemer...@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.
>
The grouping and using same application_name different server is similar.
How does the same application_name different server work?
>> 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.
If I validate s_s_name JSON syntax, I will definitely use JSONB,
rather than JSON.
Because JSONB has some useful operation functions for adding node,
deleting node to s_s_name today.
But the down side of using JSONB for s_s_name is that it could switch
in key name order place.(and remove duplicate key)
For example in the syntax Michael suggested,
* JSON (just casting JSON)
json
------------------------------------------------------------------------
{ +
"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"] +
} +
}
* JSONB (using jsonb_pretty)
jsonb_pretty
--------------------------------------
{ +
"groups": { +
"cluster1": [ +
"node11", +
"node12", +
"node13" +
], +
"cluster2": [ +
"node21", +
"node22", +
"node23" +
] +
}, +
"sync_standby_names": { +
"nodes": [ +
{ +
"group": "cluster1",+
"priority": 1 +
}, +
{ +
"nodes": [ +
"node1", +
"node2", +
"node3" +
], +
"quorum": 2 +
} +
], +
"quorum": 2 +
} +
}
"group" and "sync_standby_names" has been switched place. I'm not sure
it's good for the users.
Regards,
--
Masahiko Sawada
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
