Re: Support for N synchronous standby servers

On Wed, Sep 10, 2014 at 11:40 PM, Michael Paquier
<michael(dot)paquier(at)gmail(dot)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