From: | Jacob Coby <jcoby(at)listingbook(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: autovacuum template0 |
Date: | 2006-07-03 15:52:17 |
Message-ID: | 44A93D31.90607@listingbook.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Tom Lane wrote:
> Jacob Coby <jcoby(at)listingbook(dot)com> writes:
>> I then tried:
>> foo=# select * from pg_catalog.pg_statistic ;
>> ERROR: could not access status of transaction 3242180415
>> DETAIL: could not open file "pg_clog/0C13": No such file or directory
>
>> so it seems that pg_catalog.pg_statistic has somehow become corrupt on
>> template0?
>
> Yeah, that's what it looks like. If you're interested in digging into
> why, it'd be productive to run "pg_filedump -i -f" on the table
> (see http://sources.redhat.com/rhdb/ for that utility).
I wasn't able to build that utility due to dependencies that I didn't
have the patience to chase down.
> If you just want to get out of the problem, it's fortunately not hard
> because pg_statistic is all derived data. Go into template0, TRUNCATE
> pg_statistic, and then VACUUM ANALYZE to regenerate it and VACUUM FREEZE
> to re-freeze template0. (You'll need to fool with
> pg_database.datallowconn to let yourself into template0. Read the
> manual's bit about template databases if you aren't sure what you're
> doing here.)
That worked perfectly. Thanks.
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2006-07-03 15:52:46 | Re: Optimizing query: select ... where id = 4 and md5(...) |
Previous Message | Alban Hertroys | 2006-07-03 15:43:53 | Re: pgsql vs mysql - escaping data for COPY? |