On 06.02.2013 20:02, Robert Haas wrote:
On Wed, Feb 6, 2013 at 12:43 PM, Simon Riggs<si...@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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
