On Tue, Sep 28, 2010 at 12:46 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Mon, Sep 27, 2010 at 5:02 PM, Magnus Hagander <magnus@hagander.net> wrote:
>> On Mon, Sep 27, 2010 at 08:34, Fujii Masao <masao.fujii@gmail.com> wrote:
>>> On Mon, Sep 27, 2010 at 9:35 AM, Jaime Casanova <jaime@2ndquadrant.com> wrote:
>>>> Maybe i'm missing something but this would be a problem if we put a
>>>> trigger file and the recovery.conf gets renamed to recovery.done, no?
>>>> at least that would be a problem for the standbys that still need to
>>>> be standbys
>>>
>>> That's not problem unless more than one standbys become master at the
>>> same time. Since recovery.conf is read by standby only at the start unless
>>> it's triggered, already-started standbys can work even if recovery.conf is
>>> renamed to recovery.done. Though it's somewhat tricky..
>>
>> Uh, what if the slave is restarted for one reason or another? That
>> seems like it would be really fragile..
>
> Agreed ;)
>
> So, even if we move primary_conninfo and trigger_file to postgresql.conf,
> we would need to still leave standby_mode in recovery.conf.
The idea of relying on the existence of recovery.conf to determine
whether we should continue recovery forever or switch to normal
running seems somewhat klunky to me. It mixes up settings with
control information. Maybe the control information should move to
pg_control, and the settings to postgresql.conf. *waves hands*
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company