On Sun, Jul 18, 2010 at 3:14 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 14/07/10 09:50, Fujii Masao wrote:
>>
>> Quorum commit
>> -------------
>> In previous discussion about synchronous replication, some people
>> wanted the quorum commit feature. This feature is included in also
>> Zontan's synchronous replication patch, so I decided to create it.
>>
>> The patch provides quorum parameter in postgresql.conf, which
>> specifies how many standby servers transaction commit will wait for
>> WAL records to be replicated to, before the command returns a
>> "success" indication to the client. The default value is zero, which
>> always doesn't make transaction commit wait for replication without
>> regard to replication_mode. Also transaction commit always doesn't
>> wait for replication to asynchronous standby (i.e., replication_mode
>> is set to async) without regard to this parameter. If quorum is more
>> than the number of synchronous standbys, transaction commit returns
>> a "success" when the ACK has arrived from all of synchronous standbys.
>
> There should be a way to specify "wait for *all* connected standby servers
> to acknowledge"
Agreed. I'll allow -1 as the valid value of the quorum parameter, which
means that transaction commit waits for all connected standbys.
>> Protocol
>> --------
>> I extended the handshake message "START_REPLICATION" so that it
>> includes replication_mode read from recovery.conf. If 'async' is
>> passed, the master thinks that it doesn't need to wait for the ACK
>> from the standby.
>
> Please use self-explanatory names for the modes in START_REPLICATION
> command, instead of just an integer.
Agreed. What about changing the START_REPLICATION message to?:
START_REPLICATION XXX/XXX SYNC_LEVEL { async | recv | fsync | replay }
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
