On Fri, Jun 26, 2015 at 1:12 PM, Josh Berkus <j...@agliodbs.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers