On Fri, Jan 8, 2010 at 10:58, Heikki Linnakangas <heikki.linnakan...@enterprisedb.com> wrote: > The trigger file logic feels a bit backwards. As the patch stands, when > the standby starts up, it retries connecting to the master server > indefinitely, until a connection is successfully established. Then it > streams until the connection breaks. If the connection is dropped > abruptly, because of a network problem or crash in the master, standby > retries indefinitely. > > If master is shut down cleanly, standby gets out of recovery mode, and > starts up. Unless the trigger file is present; if it is, standby waits > for it to go away before finishing recovery. > > So the trigger file is really a "holdoff file", like a safety catch on a > gun. At the very least it should be renamed, but I don't think that's a > very useful behavior anyway. > > It doesn't seem wise to consider a clean shutdown of the master as a > signal to trigger failover. If you're setting up a HA system, that by > itself is not robust enough; you also need to trigger failover if the > master goes down unexpectedly, or if the standby was disconnected for > some reason when the master was shut down. Secondly, what if you want to > restart the master server, without initiating failover? You'll have to > restart the standby too, to have it reconnect. > > Let's have a default of no failover, and retry connecting to the master > indefinitely. When you *do* want to fail over, create the trigger file. > When the standby sees the trigger file, it should stop streaming, finish > up replaying what it had streamed up to that point, and start up as new > master.
+1. The default should be to "maintain the replication cluster", if nothing else then by principle of least surprise. It would also agree with a well-established procedure, which is what pg_standby does. Keeping the same basic behavior around something like this can only be a good thing. -- Magnus Hagander Me: http://www.hagander.net/ Work: http://www.redpill-linpro.com/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers