I'm afraid I'm exactly in this situation now.
Last entry from the 9.1.6 recommended VACUUM (FREEZE, VERBOSE, ANALYZE) was:
INFO: "meta_version_chunks": found 55363 removable, 32566245 nonremovable row versions in 450292 out of 450292 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 588315 unused item pointers.
0 pages are entirely empty.
CPU 2.44s/5.77u sec elapsed 2150.18 sec.
INFO: vacuuming "pg_toast.pg_toast_16582"
And here're are the locks held by the VACCUM backend:
select oid,relname,relkind,relpages,reltuples::numeric(15,0),reltoastrelid,reltoastidxid
from pg_class
where oid in (select relation from pg_locks where pid = 1380);
oid | relname | relkind | relpages | reltuples | reltoastrelid | reltoastidxid
-------+----------------------+---------+----------+-----------+---------------+---------------
16585 | pg_toast_16582 | t | 16460004 | 58161600 | 0 | 16587
16587 | pg_toast_16582_index | i | 188469 | 58161600 | 0 | 0
16582 | meta_version_chunks | r | 450292 | 32566200 | 16585 | 0
I will not touch anything and would like to get some recommendations on how to proceed.
2012/9/26 Robert Haas
<robertmhaas@gmail.com> On Fri, Sep 21, 2012 at 10:41 AM, Andres Freund <andres@2ndquadrant.com> wrote:
> Hrm. I retract my earlier statement about the low likelihood of corruption due
> to this.
Yeah. :-(
We've recently had at least one report of autovacuum failing to
terminate due to a series of index pages forming a circular loop, and
at least one case where it appears that the data became not-unique on
a column upon which a unique index existed, in releases that contain
this bug.
It seems therefore that REINDEX + VACUUM with
vacuum_freeze_table_age=0 is not quite sufficient to recover from this
problem. If your index has come to contain a circularity, vacuum will
fail to terminate, and you'll need to drop it completely to recover.
And if you were relying on your index to enforce a unique constraint
and it didn't, you'll need to do manual data repair before it will be
possible to rebuild or replace that index.
--
Victor Y. Yegorov
