Greg Smith wrote:
On Tue, 5 Jun 2007, Marco Colombo wrote:
AFAIK, files in pg_xlog are first renamed (and only if and after the
archive_command returned true) and later overwritten to. Never deleted.
No, they get deleted sometimes, too. Not often, but it can happen under
heavy load if more segments get temporarily created than are normally
needed. At checkpoint time, only 2*checkpoint_segments+1 xlog files are
kept; if there are more than that, they are removed. Probably never
happen on your system from what you've described of it, but it is a
possibility.
Ok, you're right. Anyway neither renames nor deletes can happen during
my backups. My archive_command prevents it.
As Simon just pointed out, the danger with the approach you're taken
comes from what happens if a checkpoint occurs in the middle of your
backup. You've probably never seen that happen either. As long as that
continues to be true, you might be OK for now, but you really need to
get to where you're following the recommended procedure rather than
trying to do something a little different. There are too many edge
cases here that could^H^H^H^H^Hwill bite you one day.
Let's say you use the standard procedure. Let's say that your
archive_commands starts failing at 1:00 AM (say, no space left on the
archive directory). Let's say your backup starts at 2:00 AM.
Later, at 8:00 AM you solve the disk full problem, and PG resumes the
archiving of WAL segments... as long as there's enough room in pg_xlog
for the extra segments, PG is fine.
Is your backup broken if a checkpoint happens during the backup? In my
understanding, no. There's no need for archiving to happen immediately.
My procedure just simulates an archiving failure during the backup, no
more, no less. The only difference is that the "problem" is solved right
after the backup. By that time, all WAL records created during the
backup have already been saved.
If you're going to archive WAL segments anyway, my procedure buys you
almost nothing. It just saves you from using a trick and artificially
fill a segment with garbage data just to have it archived right after
the backup. It does so by using another trick, so no big deal. But it
allows anyone not willing to take the burden, or face the danger, of
actually archiving logs, to take file level backups instead of pg_dumps
and without relying on external snapshotting abilities.
.TM.
