On Mon, Feb 1, 2016 at 9:28 AM, Fujii Masao <masao.fu...@gmail.com> wrote: > So what about the following plan? > > [first version] > Add only synchronous_standby_num which specifies the number of standbys > that the master must wait for before marking sync replication as completed. > This version supports simple use cases like "I want to have two synchronous > standbys". > > [second version] > Add synchronous_replication_method: 'prioriry' and 'quorum'. This version > additionally supports simple quorum commit case like "I want to ensure > that WAL is replicated synchronously to at least two standbys from five > ones listed in s_s_names". > > Or > > Add something like quorum_replication_num and quorum_standby_names, i.e., > the master must wait for at least q_r_num standbys from ones listed in > q_s_names before marking sync replication as completed. Also the master > must wait for sync replication according to s_s_num and s_s_num. > That is, this approach separates 'priority' and 'quorum' to each parameters. > This increases the number of GUC parameters, but ISTM less confusing, and > it supports a bit complicated case like "there is one local standby and three > remote standbys, then I want to ensure that WAL is replicated synchronously > to the local standby and at least two remote one", e.g., > > s_s_num = 1, s_s_names = 'local' > q_s_num = 2, q_s_names = 'remote1, remote2, remote3' > > [third version] > Add the hooks for more complicated sync replication cases.
-1. We're wrapping ourselves around the axle here and ending up with a design that will not let someone say "the local standby and at least one remote standby" without writing C code. I understand nobody likes the mini-language I proposed and nobody likes a JSON configuration file either. I also understand that either of those things would allow ridiculously complicated configurations that nobody will ever need in the real world. But I think "one local and one remote" is a fairly common case and that you shouldn't need a PhD in PostgreSQLology to configure it. Also, to be frank, I think we ought to be putting more effort into another patch in this same area, specifically Thomas Munro's causal reads patch. I think a lot of people today are trying to use synchronous replication to build load-balancing clusters and avoid the problem where you write some data and then read back stale data from a standby server. Of course, our current synchronous replication facilities make no such guarantees - his patch does, and I think that's pretty important. I'm not saying that we shouldn't do this too, of course. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers