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

Re: [Slony1-general] WAL partition overloaded--by autovacuum?

From: Richard Yen <richyen(at)iparadigms(dot)com>
To: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: "Robert Haas" <robertmhaas(at)gmail(dot)com>, "Scott Marlowe" <scott(dot)marlowe(at)gmail(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: [Slony1-general] WAL partition overloaded--by autovacuum?
Date: 2010-07-08 19:25:01
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
On Jul 8, 2010, at 12:04 PM, Kevin Grittner wrote:

> Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> I don't understand how you managed to fill up 37GB of disk with
>> WAL files.  Every time you fill up checkpoint_segments * 16MB of
>> WAL files, you ought to get a checkpoint.  When it's complete, WAL
>> segments completely written before the start of the checkpoint
>> should be recyclable.  Unless I'm confused, which apparently I am.
> You're not alone.  At first I was assuming that it was because of
> archiving, but the OP says that's turned off.  Unless it had been on
> and there wasn't a *restart* after changing the configuration, I
> can't see how this could happen, and was hoping someone else could
> cast some light on the issue.

I'm fairly confused myself.  I'm beginning to think that because data/base and data/pg_xlog were on the same partition (/db), when the /db partition filled, up the WAL files couldn't get flushed to data/base, thereby preventing data/pg_xlog from being emptied out, as per the documentation.

My concern is that--as in the original post--there were moments where 129 WAL files were generated in one minute.  Is it plausible that this autovacuum could be responsible for this?


In response to


pgsql-performance by date

Next:From: Tom LaneDate: 2010-07-08 19:27:02
Subject: Re: [Slony1-general] WAL partition overloaded--by autovacuum?
Previous:From: Harpreet singh WadhwaDate: 2010-07-08 19:20:30
Subject: Need help in performance tuning.

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