| From: | Tino Schwarze <postgresql(at)tisc(dot)de> |
|---|---|
| To: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: Recovering a database in danger of transaction wrap-around |
| Date: | 2008-01-25 19:23:42 |
| Message-ID: | 20080125192342.GA15475@easy2.in-chemnitz.de |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
On Fri, Jan 25, 2008 at 02:10:06PM -0500, Tom Lane wrote:
> > I used lsof to monitor which files the backend was actually working on. It
> > took two of the four days for it to vacuum a single table with 43
> > one-gigabyte extents. I have one table with over 300 extents. I'm looking
> > at a vacuum process which can ultimately take weeks (if not months) to
> > complete.
>
> Yipes. You are just using plain VACUUM, right, not VACUUM FULL?
> Have you checked that vacuum_cost_delay isn't enabled?
pg_dump/pg_restore may be a lot faster here - we're in an emergency
situation anyway and after that, the whole DB will be clean again, all
indices rebuilt nicely, no bloat in the tables.
Tino.
--
www.craniosacralzentrum.de
www.spiritualdesign-chemnitz.de
Tino Schwarze * Lortzingstraße 21 * 09119 Chemnitz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | NUWAN LIYANAGE | 2008-01-25 19:55:35 | backup including symbolic links? |
| Previous Message | Tom Lane | 2008-01-25 19:10:06 | Re: Recovering a database in danger of transaction wrap-around |