Search Postgresql Archives

Re: No control over max.num. WAL files

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx

-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux