On Mon, Jul 26, 2010 at 5:27 PM, Yeb Havinga <yebhavi...@gmail.com> wrote: > Fujii Masao wrote: >>> >>> Intuitively by looking at the enumeration of replication_mode I'd think >>> that >>> the sync standbys are all standby's that operate in a not async mode. >>> That >>> would be clearer with a boolean sync (or not) and for sync standbys the >>> replication_mode specified. >>> >> >> You mean that something like synchronous_replication as the recovery.conf >> parameter should be added in addition to replication_mode? Since >> increasing >> the number of similar parameters would confuse users, I don't like do >> that. >> > > I think what would be confusing if there is a mismatch between implemented > concepts and parameters. > > 1 does the master wait for standby servers on commit? > 2 how many acknowledgements must the master receive before it can continue? > 3 is a standby server a synchronous one, i.e. does it acknowledge a commit? > 4 when do standby servers acknowledge a commit? > 5 does it only wait when the standby's are connected, or also when they are > not connected? > 6..? > > When trying to match parameter names for the concepts above: > 1 - does not exist, but can be answered with quorum_standbys = 0 > 2 - quorum_standbys > 3 - yes, if replication_mode != async (here is were I thought I had to think > to much) > 4 - replication modes recv, fsync and replay bot not async > 5 - Zoltan's strict_sync_replication parameter > > Just an idea, what about > for 4: acknowledge_commit = {no|recv|fsync|replay} > then 3 = yes, if acknowledge_commit != no
Thanks for the clarification. I still like replication_mode = {async|recv|fsync|replay} rather than synchronous_replication = {on|off} acknowledge_commit = {no|recv|fsync|replay} because the former is more intuitive for me and I don't want to increase the number of parameters. We need to hear from some users in this respect. If most want the latter, of course, I'd love to adopt it. 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