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? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
