On Wed, Feb 6, 2013 at 1:47 PM, Heikki Linnakangas
<hlinnakangas@vmware.com> wrote:
> On 06.02.2013 20:02, Robert Haas wrote:
>>
>> On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs<simon@2ndquadrant.com>
>> wrote:
>>>>
>>>> 2. I don't like demoting the trigger file method to a second class
>>>> citizen. I think we should make all functionality available through both
>>>> methods. If there was a good reason for deprecating the trigger file
>>>> method, I could live with that, but this patch is not such a reason.
>>>
>>>
>>> I don't understand why we introduced a second method if they both will
>>> continue to be used. I see no reason for that, other than backwards
>>> compatibility. Enhancing both mechanisms suggests both will be
>>> supported into the future. Please explain why the second mode exists?
>>
>>
>> I agree that we should be pushing people towards pg_ctl promote. I
>> have no strong opinion about whether backward-compatibility for the
>> trigger file method is a good idea or not. It might be a little soon
>> to relegate that to second-class status, but I'm not sure.
>
>
> Both the trigger file and pg_ctl promote methods are useful in different
> setups. If you point the trigger file on an NFS mount or similar, that
> allows triggering promotion from a different host without providing shell
> access. You might want to put the trigger file on an NFS mount that also
> contains the WAL archive, for example. A promotion script that also controls
> the network routers to redirect traffic and STONITH the dead node, can then
> simply "touch /mnt/.../trigger" to promote. Sure, it could also ssh to the
> server and run "pg_ctl promote", but that requires more setup.
Good point. I hadn't thought about that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
