On Thu, Jul 22, 2010 at 5:37 PM, Yeb Havinga <yebhavinga(at)gmail(dot)com> wrote:
> Fujii Masao wrote:
>> How should the synchronous replication behave when the number of connected
>> standby servers is less than quorum?
>> 1. Ignore quorum. The current patch adopts this. If the ACKs from all
>> connected standbys have arrived, transaction commit is successful
>> even if the number of standbys is less than quorum. If there is no
>> connected standby, transaction commit always is successful without
>> regard to quorum.
>> 2. Observe quorum. Aidan wants this. Until the number of connected
>> standbys has become more than or equal to quorum, transaction commit
>> Which is the right behavior of quorum commit? Or we should add new
>> parameter specifying the behavior of quorum commit?
> Initially I also expected the quorum to behave like described by
> Aidan/option 2.
OK. But some people (including me) would like to prevent the master
from halting when the standby fails, so I think that 1. also should
be supported. So I'm inclined to add new parameter specifying the
behavior of quorum commit when the number of synchronous standbys
becomes less than quorum.
> Also, IMHO the name "quorom" is a bit short, like having
> "maximum" but not saying a max_something.
What about quorum_standbys?
> The question remains what are the sync standbys? Does it mean not-async?
It's the standby which sets replication_mode to "recv", "fsync", or "replay".
> 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.
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
In response to
pgsql-hackers by date
|Next:||From: KaiGai Kohei||Date: 2010-07-26 07:02:17|
|Subject: Re: security label support, part.2|
|Previous:||From: Markus Wanner||Date: 2010-07-26 06:48:03|
|Subject: Re: bg worker: overview|