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  (Steven Rosenstein <srosenst@us.ibm.com>)
Список 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 по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: Recovering a database in danger of transaction wrap-around
Следующее
От: NUWAN LIYANAGE
Дата:
Сообщение: backup including symbolic links?