| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Darren Reed <darrenr+postgres(at)fastmail(dot)net> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: postgres 8.2.6 core dump when initialising. |
| Date: | 2008-04-14 14:32:42 |
| Message-ID: | 2155.1208183562@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Darren Reed <darrenr+postgres(at)fastmail(dot)net> writes:
> Some time ago I saw this message:
> ERROR: index "pg_depend_reference_index" contains unexpected zero page
> at block 23
> HINT: Please REINDEX it.
> ERROR: index "table_p_hash_idx" contains unexpected zero page at block 7
> HINT: Please REINDEX it.
[ squint... ] If something is randomly zeroing out pages, and it
happens to hit pg_class, that could explain your troubles. Maybe
you are dealing with a kernel bug or flaky hardware.
>> It might be useful if we could look at a pg_filedump dump of your
>> pg_class table, too.
> How do I know which one is pg_class?
It'd be $PGDATA/base/NNN/1259 where NNN is the OID of the broken
database. With a dead system the easiest way to find out that OID
is to look at the text file $PGDATA/global/pg_database --- the
first number after a database's name is its OID.
I find that "pg_filedump -i -f FILENAME" gives the most useful output.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2008-04-14 15:45:37 | Re: postgres 8.2.6 core dump when initialising. |
| Previous Message | Darren Reed | 2008-04-14 14:04:09 | Re: postgres 8.2.6 core dump when initialising. |