Re: Trimming transaction logs after extended WAL archive failures

From: Adrian Klaver <adrian(dot)klaver(at)aklaver(dot)com>
To: Steven Schlansker <steven(at)likeness(dot)com>, "pgsql-general(at)postgresql(dot)org postgresql" <pgsql-general(at)postgresql(dot)org>
Subject: Re: Trimming transaction logs after extended WAL archive failures
Date: 2014-03-25 22:52:20
Message-ID: 533208A4.8090301@aklaver.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 03/25/2014 01:56 PM, Steven Schlansker wrote:
> 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 filled with 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 a stable size and is not shrinking. In fact, it’s still growing at a (much slower) rate.

So what is wal_keep_segments set at in postgresql.conf?

>
> I’ve seen references to people just deleting “old” segment files or using pg_resetxlog to fix this situation, however I already know 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 to reclaim some of it... Thanks for any guidance!
>
> Steven
>
>
>

--
Adrian Klaver
adrian(dot)klaver(at)aklaver(dot)com

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steven Schlansker 2014-03-25 22:54:21 Re: Trimming transaction logs after extended WAL archive failures
Previous Message Carlos Espejo 2014-03-25 22:30:51 Disk Encryption in Production