Re: Streaming Replication patch for CommitFest 2009-09

Hi,

On Tue, Sep 15, 2009 at 7:53 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> After playing with this a little bit, I think we need logic in the slave
> to reconnect to the master if the connection is broken for some reason,
> or can't be established in the first place. At the moment, that is
> considered as the end of recovery, and the slave starts up. You have the
> trigger file mechanism to stop that, but it only gives you a chance to
> manually kill and restart the slave before it chooses a new timeline and
> starts up, it doesn't reconnect automatically.

I was thinking that the automatic reconnection capability is the TODO item
for the later CF. The infrastructure for it has already been introduced in the
current patch. Please see the macro MAX_WALRCV_RETRIES (backend/
postmaster/walreceiver.c). This is the maximum number of times to retry
walreceiver. In the current version, this is the fixed value, but we can make
this user-configurable (parameter of recovery.conf is suitable, I think).

Also a parameter like retries_interval might be necessary. This parameter
indicates the interval between each reconnection attempt.

Do you think that these parameters should be introduced right now? or
the later CF?

BTW, these parameters are provided in MySQL replication.

Regards,

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