| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | "Henrik Steffen" <steffen(at)city-map(dot)de> |
| Cc: | "pg" <pgsql-general(at)postgresql(dot)org> |
| Subject: | Re: again trouble |
| Date: | 2002-07-12 13:29:38 |
| Message-ID: | 9150.1026480578@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
"Henrik Steffen" <steffen(at)city-map(dot)de> writes:
> vacuum verbose analyze zugriffsrechte
> ERROR: IndexSupportInitialize: no pg_index entry for index 14958692
> tom, could this again be due to a broken SD-RAM chip?
Perhaps. It's certainly looking more and more like you've got some
kind of hardware problem ... Postgres is just not this flaky for most
people ;-).
If you wanted to dig into it, you could pg_filedump
pg_index_indrelid_index and look to see why it doesn't have an entry for
14958692. My bet is that the entry is indeed there, but is not being
found --- either its own key is corrupted, or some nearby keys are
corrupted in a way that renders them out-of-order, causing binary search
to conclude the desired key is not present. A single-bit error in the
key field would certainly suffice to cause such a problem.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2002-07-12 13:39:16 | Re: plpgsql Cursor Mismatched Parentheses |
| Previous Message | Tom Lane | 2002-07-12 13:20:49 | Re: 7.2.1 optimises very badly against 7.2 |