The restartableRecovery patch introduces the concept of standby_mode,
where you define in the recovery.conf file that this server is acting as
a log-shipping target. We can extend that concept to a few other useful
places.
We've discussed a number of times that we can use a script that waits
indefinitely for a log file. On reflection, it seems fairly trivial to
put this directly into the backend. I've got a number of possible
designs:
1. standby_mode tests to see if restore_command fails, if so it will
test for a notification_file then loops back round for the
restore_command again. When a failover occurs the failure-sensing
mechanism writes the notification file and we bring up the standby.
2. standby_timeout - potentially usable in conjunction with
archive_timeout. The standby server loops while waiting for the
restore_command to work until it gets to standby_timeout seconds, then
automatically comes up in standby mode. Sounds great, but possibly
slightly less useful since there's no explicit instruction to perform
failover.
Both of those are very easy to implement, now that I've seen how, and
would augment the other functionality recently delivered for 8.2.
What does the panel think? Take the red pill, or stick with blue?
-- Simon Riggs EnterpriseDB http://www.enterprisedb.com