On Tue, 10 Jul 2007, Richard Huxton wrote:
Have you looked in the "backup history file":
http://www.postgresql.org/docs/8.2/static/continuous-archiving.html#BACKUP-BASE-BACKUP
"The backup history file is just a small text file. It contains the label
string you gave to pg_start_backup, as well as the starting and ending times
and WAL segments of the backup. If you used the label to identify where the
associated dump file is kept, then the archived history file is enough to
tell you which dump file to restore, should you need to do so."
Yeah, I saw that, but looking for the most recent backup history file and
blindly assuming that's what I want, regardless of what pg_stop_backup()
told me, seems like it might be problematic in some random corner cases.
For instance, in the case when the backup history file from the previous
backup is, for some reason, still around, but the backup history file from
the current run has yet to be written, then I'd backup more WAL files than
I need. That's hardly a critical error, but the general method strikes me
as far from bulletproof and there may well be another corner case I'm not
thinking of right now that *would* be a critical error.
I was hoping I could parse the output of pg_stop_backup() more cleanly
than it seems possible to do..... but, well, for reasons unclear to me,
it's not so clean to do it right.
