Re: VACUUM FULL hangs on ordinary table - Mailing list pgsql-general

From Ivan Zolotukhin
Subject Re: VACUUM FULL hangs on ordinary table
Date
Msg-id 751e56400605200538x4e7959e8p650e97c0b2e464f2@mail.gmail.com
Whole thread Raw
In response to Re: VACUUM FULL hangs on ordinary table  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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 by date:

Previous
From: "Tomi NA"
Date:
Subject: Re: ALTER SEQUENCE ... RESTART WITH [variable] problem
Next
From: kmh496
Date:
Subject: Re: another seemingly simple encoding question