what I don't see in your paper or the proposed API
is a
way to coordinate full back-ups and WAL archiving. Obviously, the PITR
Archive is only useful in reference to an existing full backup, so it is
important to be able to associate a set of PITR archives with a
full backup, or with some kind of "backup checkpoint". I'm sure that you
have a solution for this, I just didn't see it explained in your proposal,
didn't understand it.
You are perceptive, and generous in imagining I have a good solution. I
will document this, assuming no better ideas emerge:

My understanding is this:
When crash recovery occurs, recovery starts from this last checkpoint,
not from the earliest log. Existing function caters for locating start
of xlogs for recovery purposes.
Relying upon that, it should be possible to have a backup coordinate
with a stream of xlogs at recovery time, but not EXACTLY at backup time.
Best practice would indicate that you should always maintain 2-3 full
backups, so deleting xlogs immediately after a backup is not a very good
idea at all.

In general, the usage is going to be:
- start archiver
- start PostgreSQL
- interval during which xlogs are backed up
- start backup

Best Regards, Simon Riggs

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 9 of 23 | next ›
Discussion Overview
grouppgsql-hackers @
postedMar 8, '04 at 11:28p
activeMar 12, '04 at 4:52p



site design / logo © 2021 Grokbase