On Thu, Sep 26, 2013 at 4:19 PM, David Rennalls wrote:
> On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate wrote:
>> I have seen this issue on a slave although it was in version 9.2. I ran
>
> oh ok. Looks like the issue was fixed in 8.2.23 according to these
> release notes http://www.postgresql.org/docs/8.2/static/release-8-2-23.html
> ...
> o Fix race condition during toast table access from stale syscache
> entries (Tom Lane)
>
>The typical symptom was transient errors like "missing chunk number
> 0 for toast value N in pg_toast_2619", where the
> cited toast table would always belong to a system catalog.
>
>
> .. but maybe there's a different flavour of this bug ?
Actually forgot to mention in my case there were filesystem issues...
so that might explain it. fsck was run and did some repairs after
which the error above started happening.
>> this
>>
>> select 2619::regclass;
>>regclass
>> --
>> pg_statistic
>> (1 row)
>>
>>
>> I was able to fix my select issue by running analyze on the database
>
> Yes I tried that but didn't seem to help...
> mydb=# ANALYZE verbose;
> INFO: analyzing "pg_catalog.pg_type"
> INFO: "pg_type": scanned 13 of 13 pages, containing 590 live rows and
> 0 dead rows; 590 rows in sample, 590 estimated total rows
> INFO: analyzing "pg_catalog.pg_attribute"
> INFO: "pg_attribute": scanned 78 of 78 pages, containing 4633 live
> rows and 0 dead rows; 4633 rows in sample, 4633 estimated total rows
> INFO: analyzing "information_schema.sql_features"
> INFO: "sql_features": scanned 7 of 7 pages, containing 649 live rows
> and 0 dead rows; 649 rows in sample, 649 estimated total rows
> ERROR: missing chunk number 0 for toast value 33255 in pg_toast_2619
..Tried reindexing pg_statistic based on some other posts I saw, but
was getting this error...
mydb=# REINDEX TABLE pg_statistic;
ERROR: could not create unique index "pg_statistic_relid_att_index"
DETAIL: Table contains duplicated values.
..came across this thread
http://www.spinics.net/lists/pgsql-admin/msg05911.html and I tried
simply deleting all the stuff in pg_statistic, reindex then vacuum and
that seems to have worked.
mydb=# delete from pg_statistic;
DELETE 610
mydb=# reindex table pg_statistic;
REINDEX
mydb=# vacuum analyze;
- David
--
Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-bugs
