I just completed my first online backup and recovery cycle in a test
environment.
I encountered a minor hiccup at step 8 of the process outlined in the
docs in 23.3.3, "Recovering with an On-line Backup":
http://www.postgresql.org/docs/8.1/static/backup-online.html#BACKUP-
PITR-RECOVERY
A base backup taken from a running postmaster will still include a
postmaster.pid file, which will prevent a new postmaster from being
able to be started.
As a quick fix, a note could be added to item 4 of the recovery
process that reads something like the following:
Note: If you are recovering to a new cluster and your base backup was
taken from a running postmaster, you will need to remove
postmaster.pid if it exists in order to start the new postmaster.
In reviewing this section of the documentation, though, I'm wondering
if it might not be more clearly broken into 3 further subsections. I
would suggest:
23.3.3.1 - Inline (or In-place) Recovery
23.3.3.2 - Remote Recovery or Recovery into a New Cluster
23.3.3.3 - Continuous Recovery
The "Inline Recovery" section would just be the existing 23.3.3
repurposed.
The "Remote/New Cluster Recovery" section would be an edited version
of the existing 23.3.3 to eliminate step1 and include the note
suggested above.
The "Continuous Recovery" section would include details of how to
continuously apply WAL files to a separate cluster in order to have a
true hot standby system.
Thoughts?
I'd be happy to draft 23.3.3.2. I'll have to figure out how to
implement Simon Riggs's suggestion of a wait-for-files
recover_command including a way to interrupt in the event of a need
for actual failover-style recovery before I could draft 23.3.3.3,
though.
--
Thomas F. O'Connell
Database Architecture and Programming
Co-Founder
Sitening, LLC
http://www.sitening.com/
3004 B Poston Avenue
Nashville, TN 37203-1314
615-260-0005 (cell)
615-469-5150 (office)
615-469-5151 (fax)
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
