Bruce Momjian wrote:
> What PostgreSQL version are you using? I know the *.backup file removal
> was added in 8.1:
>
> * Remove old "*.backup" files when we do pg_stop_backup() (Bruce)
> This prevents a large number of "*.backup" files from existing in
> "/pg_xlog".
>
> but the existance of the files should not cause problems.
It's 8.1.4, running on FC 5.
It does not cause any active problems, but the WAL archiving fails until
the *.backup and *.done files are removed manually, after which all the
"ready" WAL segments are archived away normally.
The script I supply to archive_command just mounts a windows share,
performs a cp (similar to the example in the PITR doc) and unmounts the
share again.
The online backup script basically just calls pg_start_backup(),
tar-gzips $PGDATA, then calls pg_stop_backup(). During that process, a
*.backup file is copied to the archive area (the windows share) using
the script supplied to archive_command.
After the online backup script runs, all subsequent attempts to run
archive_command fail because the first thing it tries to archive away is
the still-existing *.backup file. This fails because a copy already
exists in the archive area and the script refuses to overwrite the
existing file.
I thought it might be network-related (by the added delay), but simply
running pg_start_backup() and pg_stop_backup() - without actually doing
anything in between - produced the same result: I get a *.backup and
*.done file which aren't removed.
This only applies to *.backup / *.done pairs. I watched WAL segments go
from *.ready to *.done, after which the *.done files were removed from
pg_xlog/archive_status.
Best Regards,
Chris
--
Christian Kastner
PGP Key: AE90E13f
---------------------------(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
