Trimming transaction logs after extended WAL archive failures - Mailing list pgsql-general

From Steven Schlansker
Subject Trimming transaction logs after extended WAL archive failures
Date
Msg-id 94078C9A-1F27-4A51-9218-6F3181A2DF6B@likeness.com
Whole thread Raw
Responses Re: Trimming transaction logs after extended WAL archive failures  (Adrian Klaver <adrian.klaver@aklaver.com>)
Re: Trimming transaction logs after extended WAL archive failures  (Jeff Janes <jeff.janes@gmail.com>)
List pgsql-general
Hi everyone,

I have a Postgres 9.3.3 database machine.  Due to some intelligent work on the part of someone who shall remain
nameless,the WAL archive command included a ‘> /dev/null 2>&1’ which masked archive failures until the disk entirely
filledwith 400GB of pg_xlog entries. 

I have fixed the archive command and can see WAL segments being shipped off of the server, however the xlog remains at
astable size and is not shrinking.  In fact, it’s still growing at a (much slower) rate. 

I’ve seen references to people just deleting “old” segment files or using pg_resetxlog to fix this situation, however I
alreadyknow that the response from the mailing list will be “that’s insane, don’t do that”. 

So what is the correct solution to pursue here?  The steady state of the machine should have enough space, I just need
toreclaim some of it...  Thanks for any guidance! 

Steven



pgsql-general by date:

Previous
From: Tom Lane
Date:
Subject: Re: tsearch2: how to plainto_tsquery() with "|"
Next
From: Brian Crowell
Date:
Subject: PG choosing nested loop for set membership?