Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.

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(at)gmail(dot)com>

> On Fri, Sep 21, 2012 at 10:41 AM, Andres Freund <andres(at)2ndquadrant(dot)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