From: | Виктор Егоров <vyegorov(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
Date: | 2012-09-26 05:57:06 |
Message-ID: | CAGnEboi4bNEH-QQ4xs=9gzrN9VAWh16-775bL=zev61sMNMx-g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Виктор Егоров | 2012-09-26 06:12:37 | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
Previous Message | Robert Haas | 2012-09-26 00:42:35 | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
From | Date | Subject | |
---|---|---|---|
Next Message | Виктор Егоров | 2012-09-26 06:12:37 | Re: [COMMITTERS] pgsql: Properly set relpersistence for fake relcache entries. |
Previous Message | Jaime Casanova | 2012-09-26 05:55:55 | Re: system_information.triggers & truncate triggers |