On Wed, Feb 6, 2013 at 1:47 PM, Heikki Linnakangas <hlinnakan...@vmware.com> wrote: > 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.
Good point. I hadn't thought about that. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
