On Mon, Feb 1, 2016 at 11:28 PM, Fujii Masao wrote:
[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.,
[third version] Add the hooks for more complicated sync replication cases.
I'm thinking that the realistic target for 9.6 might be the first one.
If we want to get something out for this release, clearly yes, and being able to specify 2 sync targets is already a win when the two sync standbys are not exactly at the same location. FWIW, I don't doing coding and/or review work, that's basically my first patch that needs a bit more love and polishing, *and* test cases but I am used enough to perl and PostgresNode these days to produce something based on sanity checks of pg_stat_replication and my other set of patches that have more basic routines.
Now I would not mind if we actually jump into the 3rd case if we are fine with doing nothing for this release, but this requires a lot of design and background work, so that's not plausible for 9.6. Of course if there are voices against the scenario proposed by Fujii-san others feel free to speak up. --