Re: pg_xlog becomes extremely large during CREATE INDEX

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Vivek Khera <khera(at)kcilink(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: pg_xlog becomes extremely large during CREATE INDEX
Date: 2004-05-15 03:55:34
Message-ID: 3124.1084593334@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Vivek Khera <khera(at)kcilink(dot)com> writes:
> "TL" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> TL> ... On looking at the code I see that it doesn't make any
> TL> attempt to prune future log segments after a decrease in
> TL> checkpoint_segments, so if a previous misconfiguration had allowed the
> TL> number of future segments to get really large, that could be the root of
> TL> the issue.

> Wow... that explains it!

> I bumped up checkpoint segments to 50 for a restore since it made it
> run way faster. In normal operation I don't need that many so I
> dropped it back down but it didn't reclaim any space so I figured I
> might as well keep it at 50...

How long did you wait? I believe the code will prune excess segments as
they come around to be recycled. It just doesn't kill them immediately.

I think that part of what's going on in Jeff's example is that he's
looking at the state immediately after a spike in database traffic, and
not having any patience to see if the system will recover after some
period with more-normal traffic levels.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2004-05-15 04:23:18 Re: pg_xlog becomes extremely large during CREATE INDEX
Previous Message Ed L. 2004-05-14 22:51:12 Re: Identifying diskspace leakage