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 <robertmh...@gmail.com> > On Fri, Sep 21, 2012 at 10:41 AM, Andres Freund <and...@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
