Skip site navigation (1) Skip section navigation (2)

Re: Limiting size and number of transaction logs

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: cjwhite(at)cisco(dot)com
Cc: pgsql-admin(at)postgresql(dot)org
Subject: Re: Limiting size and number of transaction logs
Date: 2005-01-15 01:35:31
Message-ID: 27796.1105752931@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-admin
"Chris White (cjwhite)" <cjwhite(at)cisco(dot)com> writes:
> In the documentation for 7.4 for WAL configuration, I see the following
> statement:
> There will be at least one 16 MB segment file, and will normally not be more
> than 2 * checkpoint_segments + 1 files. 
 
> So if I have 1 checkpoint segment configured, does this mean there will be a
> max of 4 16MB files or 3 16MB files. 

Note the word "normally" --- there's no guarantees here.  A spike in WAL
output rate could result in more WAL segments than usual.  But if you
have checkpoint_segments = 1 and the system never generates more than
16MB of WAL output before the next checkpoint can complete, there'd
probably be only two WAL segments.  The formula says three, but what
that actually means is that the checkpoint logic will allow up to three
to exist without trying to get rid of any.  I think that with a low
enough output rate, it would flip between two segments without ever
trying to make a third one.

> Is there anyway of reducing this number of files, as I am running on a
> system which is very tight on disk space and doesn't have that much DB
> transaction  throughput that needs this number of transaction logs or is
> there a way of making the size smaller?

In 8.0 the segment size can be configured at compile time, but I don't
think I'd risk it in earlier releases.

			regards, tom lane

In response to

Responses

pgsql-admin by date

Next:From: Tom ArthursDate: 2005-01-15 02:25:26
Subject: Re: hi people
Previous:From: Michael FuhrDate: 2005-01-15 00:56:00
Subject: Re: Script terminates even though ON_ERROR_STOP not set

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group