On Wed, Sep 10, 2014 at 11:40 PM, Michael Paquier <michael.paqu...@gmail.com> wrote: > Currently two nodes can only have the same priority if they have the > same application_name, so we could for example add a new connstring > parameter called, let's say application_group, to define groups of > nodes that will have the same priority (if a node does not define > application_group, it defaults to application_name, if app_name is > NULL, well we don't care much it cannot be a sync candidate). That's a > first idea that we could use to control groups of nodes. And we could > switch syncrep.c to use application_group in s_s_names instead of > application_name. That would be backward-compatible, and could open > the door for more improvements for quorum commits as we could control > groups node nodes. Well this is a super-set of what application_name > can already do, but there is no problem to identify single nodes of > the same data center and how much they could be late in replication, > so I think that this would be really user-friendly. An idea similar to > that would be a base work for the next thing... See below.
In general, I think the user's requirement for what synchronous standbys could need to acknowledge a commit could be an arbitrary Boolean expression - well, probably no NOT, but any amount of AND and OR that you want to use. Can someone want A OR (((B AND C) OR (D AND E)) AND F)? Maybe! Based on previous discussions, it seems not unlikely that as soon as we decide we don't want to support that, someone will tell us they can't live without it. In general, though, I'd expect the two common patterns to be more or less what you've set forth above: any K servers from set X plus any L servers from set Y plus any M servers from set Z, etc. However, I'm not confident it's right to control this by adding more configuration on the client side. I think it would be better to stick with the idea that each client specifies an application_name, and then the master specifies the policy in some way. One advantage of that is that you can change the rules in ONE place - the master - rather than potentially having to update every client. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
