On 25.03.2011 03:00, Daniel Farina wrote:
Here is the mechanism: I want to author a recovery.conf to perform some amount of restore_command or streaming replication based recovery, but I do *not* want to generate a new timeline. Rather, I want to stay in hot standby mode to allow read-only connections.
That's exactly what the standby mode is for. Add "standby_mode=on" to recovery.conf, and the server will do exactly that.
Perhaps the documentation is not clear on this. Any suggestions on how to improve that?
InArchiveRecovery gets set to "true" as soon as readRecoveryCommandFile completes basically normally, and it looks as though that will ensure we will get a new timeline. If one tries a bizarre hack, like ensuring the restore_command does not terminate, one never finishes recovery
That's what pg_standby does. That was the only option before standby_mode was introduced, in version 9.0, although we didn't have hot standby until 9.0 either.
-- as one may expect -- and one cannot connect to the server -- which one may not expect is necessarily the case presuming hot standby, if the server was terminated cleanly.
That's not true. As long as you enable hot standby, the server will accept connections while restore command is running.
The things I want to do with the ability to suppress a new timeline: * Offline WAL application -- I want to be able to bring up a second server, perform some amount of point in time recovery, and then stop and archive. It would be nice to support read-only queries in this case to test the recovered database. The goal of this is to reduce recovery time in a disaster scenario without tying up resources on a live server.
Yep, that can be done with standby_mode=on.
* The ability to quiesce a system by bringing it into read-only state that generates no new WAL while still being able to ship old WAL.
In theory it should be possible to stop a server, put it into hot standby mode by creating a recovery.conf file, and restart, but it won't try ship the old WAL after that. When you stop a server it will try to archive all existing WAL before exiting, though.
-- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
