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.
- Group names: to simplify status reporting
- Nesting: At least 2 levels of nesting
Using JSON, sync rep parameter to replicate in 2 different clusters could be
written as:
{"remotes": {"quorum": 2, "servers": [{"london": {"prioirty": 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])'
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
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.
Thoughts?
-----
Beena Emerson
--
View this message in context:
http://postgresql.nabble.com/Support-for-N-synchronous-standby-servers-take-2-tp5849384p5858571.html
Sent from the PostgreSQL - hackers mailing list archive at Nabble.com.