When I'm saying it left the files there, it left ALL the files there - over
3 weeks worth, and it kept producing new WAL files.
The archive command was succeeding as I was getting a copy in my backup
directory, and I was getting through an average of 3-4 files a day, so
surely if it wanted to recycle the original files it would have done by
then, rather than keep creating new files? The checkpoint settings were all
at default values.
Thanks for clarifying the archive command's job - I hadn't realised WAL
segments are recycled, due to the above issue.
> -----Original Message-----
> From: pgsql-admin-owner@postgresql.org [mailto:pgsql-admin-
> owner@postgresql.org] On Behalf Of Tom Lane
> Sent: 22 June 2006 3:22 pm
> To: andy.shellam@mailnetwork.co.uk
> Cc: 'Alvaro Herrera'; pgsql-admin@postgresql.org
> Subject: Re: [ADMIN] 2,2gb of pg_xlog ??
>
> "Andy Shellam" <andy@andycc.net> writes:
> >> Don't do this. Postgres itself will remove the file after the
> >> archive_command has copied it elsewhere.
>
> > In my 8.1.3 install, it didn't - when I specified a cp command, it left
> the
> > files there. I had to define the command as "mv" to have them moved.
>
> If it left the files there, it had a reason to (probably, that it wanted
> to rename them for use as new WAL segments). It is NOT NOT NOT the job
> of the archive_command to do anything except copy the data somewhere else.
>
> Back to the OP's problem: failure to recycle WAL segments requires some
> active looking into, not mindless removal of files. The only
> explanations I can think of are that he's got the checkpoint interval
> settings at wacko values, or more likely something is preventing
> checkpoints from completing; if so, it's desperately important to find
> out what and fix it. Manual file removal is addressing a symptom not
> the problem.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: don't forget to increase your free space map settings
>
> !DSPAM:14,449aa805256841107475365!
>