Re: VACUUM FULL hangs on ordinary table

Поиск
Список
Период
Сортировка
От Ivan Zolotukhin
Тема Re: VACUUM FULL hangs on ordinary table
Дата
Msg-id 751e56400605200538x4e7959e8p650e97c0b2e464f2@mail.gmail.com
обсуждение исходный текст
Ответ на Re: VACUUM FULL hangs on ordinary table  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-general
On 5/19/06, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Ivan Zolotukhin" <ivan.zolotukhin@gmail.com> writes:
> > quite ordinary I think. When it hangs I see in `ps auxww` process with
> > "VACUUM waiting" in its status.
>
> It's definitely waiting for a lock then.

Yep, I checked that it waits for acquiring AccessExclusiveLock on the
next table to vacuum after it finished "education" table.

>
> > Below I pasted last lines concerning above table from VACUUM output
> > (it stops after the last line):
> > ...
> > INFO:  analyzing "public.education"
> > INFO:  "education": scanned 674 of 674 pages, containing 40653 live
> > rows and 1111 dead rows; 3000 rows in sample, 40653 estimated total
> > rows
>
> If it hangs there then I'd venture that it's trying to get writer's
> lock (RowExclusiveLock) on pg_statistic so it can store the new
> statistic rows.  Or possibly pg_class.  You should be looking for locks
> on the system catalogs not locks on "education" itself.

Actually, Joachim was closer to the truth: there was one not committed
prepared transaction started several days ago (client disconnected at
the beginning) that holded one RowExclusiveLock and 12
AccessShareLocks on several relations in that DB (that obviously
interfered with vacuum trying to acquire AccessExclusiveLock on one of
them). After ROLLBACK PREPARED vacuum works fine so thanks to your
advices -- they helped me to solve the problem.

Regards,
Ivan Zolotukhin

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

Предыдущее
От: "Tomi NA"
Дата:
Сообщение: Re: ALTER SEQUENCE ... RESTART WITH [variable] problem
Следующее
От: kmh496
Дата:
Сообщение: Re: another seemingly simple encoding question