On Fri, Sep 3, 2010 at 3:42 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
> Here is the proposed detailed design:
>
> standbys.conf
> =============
> # This is not initialized by initdb, so users need to create it under $PGDATA.
> * The template is located in the PREFIX/share directory.
>
> # This is read by postmaster at the startup as well as pg_hba.conf is.
> * In EXEC_BACKEND environement, each walsender must read it at the startup.
> * This is ignored when max_wal_senders is zero.
> * FATAL is emitted when standbys.conf doesn't exist even if max_wal_senders
> is positive.
>
> # SIGHUP makes only postmaser re-read the standbys.conf.
> * New configuration doesn't affect the existing connections to the standbys,
> i.e., it's used only for subsequent connections.
> * XXX: Should the existing connections react to new configuration? What if
> new standbys.conf doesn't have the standby_name of the existing
> connection?
>
> # The connection from the standby is rejected if its standby_name is not listed
> in standbys.conf.
> * Multiple standbys with the same name are allowed.
>
> # The valid values of SYNCHRONOUS field are async, recv, fsync and replay.
>
> standby_name
> ============
> # This is new string-typed parameter in recovery.conf.
> * XXX: Should standby_name and standby_mode be merged?
>
> # Walreceiver sends this to the master when establishing the connection.
The attached patch implements the above and simple synchronous replication
feature, which doesn't include quorum commit capability. The replication
mode (async, recv, fsync, replay) can be specified on a per-standby basis,
in standbys.conf.
The patch still uses a poll loop in the backend, walsender, startup process
and walreceiver. If a latch feature Heikki proposed will have been committed,
I'll replace that with a latch.
The documentation has not fully updated yet. I'll work on the document until
the deadline of the next CF.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center