Re: Parameter name standby_mode

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема Re: Parameter name standby_mode
Дата
Msg-id 3f0b79eb1002112228m7de0d371v44b69cb65e328622@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Parameter name standby_mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Ответы Re: Parameter name standby_mode  (Joachim Wieland <joe@mcknight.de>)
Re: Parameter name standby_mode  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Список pgsql-hackers
On Fri, Feb 12, 2010 at 3:19 PM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> Fujii Masao wrote:
>> On Wed, Feb 10, 2010 at 8:16 PM, Heikki Linnakangas
>> <heikki.linnakangas@enterprisedb.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


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: Parameter name standby_mode
Следующее
От: Joachim Wieland
Дата:
Сообщение: Re: Parameter name standby_mode