Re: Recovering a database in danger of transaction wrap-around
От | Tino Schwarze |
---|---|
Тема | Re: Recovering a database in danger of transaction wrap-around |
Дата | |
Msg-id | 20080125192342.GA15475@easy2.in-chemnitz.de обсуждение исходный текст |
Ответ на | Re: Recovering a database in danger of transaction wrap-around (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Recovering a database in danger of transaction wrap-around
|
Список | 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
В списке pgsql-admin по дате отправления: