Greg Smith wrote:
He's talking about wiping out the ones on the backup server, so I
think Johannes means erasing the old archived logs on the secondary
here. That can screw up your backup if you do it wrong, but it's not
an all-caps worthy mistake.
yes, that's what I am talking about related to
http://www.postgresql.org/docs/8.2/interactive/continuous-archiving.html.
Sorry, if that did not came out clearly enough.
On Wed, 13 Jun 2007, Johannes Konert wrote:
Because I do not want to rely on creation-date,
No, you want to rely on creation date, because then this problem goes
away.
Truely right...if I can gurantee, that the file-dates of my archived
WAL-files do have proper timestamps. If the timestamps once are messed
up and all have the same timestamp (due to a Windows-copy or something
else foolish), then the delete-script might delete the wrong files...
The idea you should be working toward is that you identify when your
last base backup was started after it's copied to the secondary, and
then you can safely delete any archived logs file on the secondary
from before that time. Instead of doing "ls | sort -g -r" you should
be doing something like looping over the files in a bash shell script
and using
[ -ot <first xlog in base backup> ] to determine which files to delete.
right; but as I said, then I rely on file-dates.
But during the day I came out with an solution: I store the WAL-files
with the time-stamp of archiving in their file-name. Thus I can order
and delete them safely.
Your hint was the one, that helped me to find that solution - so thanks
for that, Greg.....and the others.
Regards,
Johannes
