Re: Vacuum Full Analyze Stalled

Поиск
Список
Период
Сортировка
От Jeff Kirby
Тема Re: Vacuum Full Analyze Stalled
Дата
Msg-id s340e931.008@gwmta.wicourts.gov
обсуждение исходный текст
Ответ на Vacuum Full Analyze Stalled  ("Jeff Kirby" <Jeff.Kirby@wicourts.gov>)
Список pgsql-admin
Thanks Tom...

The Linux box was completely idle (as you already guessed).  There were multiple locks on the table(s) in question.
Andto answer your question, we are heavily using domain types.  I suspect (to refresh your memory) that the problem
reportedearlier was from Kevin Grittner.  Do you know if there are any plans to have better utilization of domain types
inPostgres? 

The steps I took to resolve the problem was to completely kill all processes, restarted the Postgres service, and then
ran"vacuum full analyze" upon a successful restart.  That went through without a hitch.   

Thanks again... let me know if you can think of anything that could/would prevent this problem in the future (outside
ofeliminating domain types). 

Jeff Kirby

>>> Tom Lane <tgl@sss.pgh.pa.us> 10/02/05 8:53 PM >>>
"Jeff Kirby" <Jeff.Kirby@wicourts.gov> writes:
> the Linux box however is still chugging away this morning... and
> appears to be stuck on vacuuming "pg_constraint_contypid_index".  How
> do I know... well I don't really... I'm inferring based on the order
> of the log output on the Windows box.

Looking in pg_locks would give you a more reliable indicator of what the
VACUUM is currently working on.

Is the Linux box otherwise idle?  There was another report recently of a
vacuum hung up for a long time on pg_constraint_contypid_index, but it
seemed to be due to extremely heavy usage of domain types ...

            regards, tom lane


В списке pgsql-admin по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: FW: truncate error
Следующее
От: Ronaldo
Дата:
Сообщение: two instances of Postgres in the same server