On Tue, May 25, 2010 at 11:36 PM, Fujii Masao <masao.fu...@gmail.com> wrote: > On Wed, May 26, 2010 at 2:10 AM, Simon Riggs <si...@2ndquadrant.com> wrote: >> My suggestion is simply to have a single parameter (name unimportant) >> >> number_of_synch_servers_we_wait_for = N >> >> which is much easier to understand because it is phrased in terms of the >> guarantee given to the transaction, not in terms of what the admin >> thinks is the situation. > > How can we choose #2, #3 or #4 by using your proposed option? > > As the result of the discussion, I'm inclined towards choosing the > "mix" approach. How about specifying #1, #2, #3 or #4 per standby, > and specifying the number of "synchronous" (i.e., means #2, #3 or > #4) standbys the transaction commit waits for at the master as > Simon suggests? > > We add new option "replication_mode" (better name?) specifying > when the standby sends the ACK meaning the completion of replication > to the master into recovery.conf. Valid values are "async", "recv", > "fsync" and "redo". Those correspond to #1, #2, #3 and #4 I defined > on the top of the thread. > > If "async", the standby never sends any ACK. If "recv", "fsync", > or "redo", the standby sends the ACK when it has received, fsynced > or replayed the WAL from the master, respectively. > > On the other hand, we add new GUC "max_synchronous_standbys" > (I prefer it to "number_of_synch_servers_we_wait_for", but does > anyone have better name?) as PGC_USERSET into postgresql.conf. > It specifies the maximum number of standbys which transaction > commit must wait for the ACK from. > > If max_synchronous_standbys is 0, no transaction commit waits for > ACK even if some connected standbys set their replication_mode to > "recv", "fsync" or "redo". If it's positive, transaction comit waits > for N ACKs. N is the smaller number between max_synchronous_standbys > and the actual number of connected "synchronous" standbys. > > Thought?
I think we're over-engineering this. For a first version we should do something simple. Then we can add some of these extra knobs in a follow-on patch. Quorum commit is definitely an extra knob, IMHO. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise Postgres Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
