Re: Synchronous replication - patch status inquiry

From: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us>, fazool mein <fazoolmein(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Synchronous replication - patch status inquiry
Date: 2010-09-03 06:42:51
Message-ID: AANLkTi=baRnkqQXC6S_P-vE-TGh9VhPD+Z3KEQ30fopB@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Sep 2, 2010 at 7:24 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> I propose a configuration file standbys.conf, in the master:
>>
>> # STANDBY NAME    SYNCHRONOUS   TIMEOUT
>> importantreplica  yes           100ms
>> tempcopy          no            10s
>
> Seems good. In fact, instead of yes/no, async/recv/fsync/replay is specified
> in SYNCHRONOUS field?
>
> OTOH, something like standby_name parameter should be introduced in
> recovery.conf.
>
> We should allow multiple standbys with the same name? Probably yes.
> We might need to add NUMBER field into the standbys.conf, in the future.

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.

Comments? Is the above too complicated for the first step? If so, I'd
propose to just introduce new recovery.conf parameter like replication_mode
specifying the synchronization level, instead.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2010-09-03 06:55:37 Re: Synchronous replication - patch status inquiry
Previous Message Simon Riggs 2010-09-03 06:36:27 Re: Synchronous replication - patch status inquiry