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.
