Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.
Date
Msg-id CA+TgmoZkB0tXUWnRWQJbejeVbiZao1BGNVF5v0aXrR2XRX54xw@mail.gmail.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Andres Freund <andres@2ndquadrant.com>)
Responses Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Виктор Егоров <vyegorov@gmail.com>)
Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries.  (Devrim GÜNDÜZ <devrim@gunduz.org>)
List pgsql-hackers
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.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: pg_reorg in core?
Next
From: Andrew Dunstan
Date:
Subject: Re: Oid registry