From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Parameter name standby_mode |
Date: | 2010-02-12 06:28:19 |
Message-ID: | 3f0b79eb1002112228m7de0d371v44b69cb65e328622@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Fujii Masao wrote:
>> On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
>> <heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
>>> If they want to implement the warm standby using the (new) built-in
>>> logic to keep retrying restore_command, they would set
>>> standby_mode='on'. standby_mode='on' doesn't imply streaming replication.
>>
>> But if we fail in restoring the archived WAL file, "standby_mode = on"
>> *always* tries to start streaming replication.
>
> Hmm, somehow I thought it doesn't if you don't set primary_conninfo. I
> think that's the way it should work, ie. if primary_conninfo is not set,
> don't launch walreceiver but just keep trying to restore from the archive.
Yeah, even if primary_conninfo is not given, the standby tries to invoke
walreceiver by using the another connection settings (environment variables
or defaults). This is intentional behavior, and would make the setup of SR
easier. So I'd like to leave it be.
Regards,
--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center
From | Date | Subject | |
---|---|---|---|
Next Message | Joachim Wieland | 2010-02-12 06:47:54 | Re: Parameter name standby_mode |
Previous Message | Heikki Linnakangas | 2010-02-12 06:19:34 | Re: Parameter name standby_mode |