Re: Support for N synchronous standby servers - take 2

On Fri, Jun 26, 2015 at 1:12 PM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:
> This really feels like we're going way beyond what we want a single
> string GUC. I feel that this feature, as outlined, is a terrible hack
> which we will regret supporting in the future. You're taking something
> which was already a fast hack because we weren't sure if anyone would
> use it, and building two levels on top of that.
>
> If we're going to do quorum, multi-set synchrep, then we need to have a
> real management interface. Like, we really ought to have a system
> catalog and some built in functions to manage this instead, e.g.
>
> pg_add_synch_set(set_name NAME, quorum INT, set_members VARIADIC)
>
> pg_add_synch_set('bolivia', 1, 'bsrv-2,'bsrv-3','bsrv-5')
>
> pg_modify_sync_set(quorum INT, set_members VARIADIC)
>
> pg_drop_synch_set(set_name NAME)
>
> For users who want the new functionality, they just set
> synchronous_standby_names='catalog' in pg.conf.
>
> Having a function interface for this would make it worlds easier for the
> DBA to reconfigure in order to accomodate network changes as well.
> Let's face it, a DBA with three synch sets in different geos is NOT
> going to want to edit pg.conf by hand and reload when the link to Brazil
> goes down. That's a really sucky workflow, and near-impossible to automate.

I think your proposal is worth considering, but you would need to fill
in a lot more details and explain how it works in detail, rather than
just via a set of example function calls. The GUC-based syntax
proposal covers cases like multi-level rules and, now, prioritization,
and it's not clear how those would be reflected in what you propose.

> Finally, while I'm raining on everyone's parade: the mechanism of
> identifying synchronous replicas by setting the application_name on the
> replica is confusing and error-prone; if we're building out synchronous
> replication into a sophisticated system, we ought to think about
> replacing it.

I'm not averse to replacing it with something we all agree is better.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company