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.
- Heikki
