Hi, On Tue, Sep 15, 2009 at 7:53 PM, Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
