Re: No control over max.num. WAL files - Mailing list pgsql-general

From Andrew Sullivan
Subject Re: No control over max.num. WAL files
Date
Msg-id 20110525120806.GC10984@shinkuro.com
Whole thread Raw
In response to No control over max.num. WAL files  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Responses Re: No control over max.num. WAL files  (Rafael Martinez <r.m.guerrero@usit.uio.no>)
Re: No control over max.num. WAL files  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-general
On Wed, May 25, 2011 at 01:30:35PM +0200, Rafael Martinez wrote:
> I am using 'pg_dumpall | psql' in the process and everything works ok
> until our pg_xlog partition gets full.
>
> According to the documentation [1] we can expect a maximum of
> (3 * checkpoint_segments + 1 segment files) WAL files in pg_xlog.

That isn't what the documentation says.  It says this:

    If, due to a short-term peak of log output rate, there are more
    than 3 * checkpoint_segments + 1 segment files, the unneeded
    segment files will be deleted instead of recycled until the system
    gets back under this limit.

Note that "unneeded".  Obviously, you need more than that, probably
because you're restoring the database in one transaction (so none of
the files can be flushed).

> In our system this will be (3 * 128 + 1) = 385 WAL files (~6GB)
>
> We have taken this into account + some extra space.
>
> Our pg_xlog partition is ~8GB and under the restore process 486 WAL
> files were created in this partition. The partition got full and
> everything crashed.

Disk is cheap.  8G is hardly anything any more; I'd buy some more disk for WAL.

A


--
Andrew Sullivan
ajs@crankycanuck.ca

pgsql-general by date:

Previous
From: Leif Jensen
Date:
Subject: Re: Postgres 8.3.5 - ECPG and the use of descriptors and cursors in multi-threaded programs
Next
From: Rafael Martinez
Date:
Subject: Re: No control over max.num. WAL files