On Thu, Sep 26, 2013 at 4:19 PM, David Rennalls <drenna...@gmail.com> wrote: > On Thu, Sep 26, 2013 at 3:40 PM, Kim Applegate <kappleg...@apsalar.com> 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 NNNNN 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