To: Darren Reed <darrenr+postgres@fastmail.net>
cc: pgsql-admin@postgresql.org
Subject: Re: postgres 8.2.6 core dump when initialising. 
In-reply-to: <48036459.7040503@fastmail.net> 
References: <4802F108.2090709@fastmail.net> <1071.1208179948@sss.pgh.pa.us>
	<48036459.7040503@fastmail.net>
Comments: In-reply-to Darren Reed <darrenr+postgres@fastmail.net>
	message dated "Mon, 14 Apr 2008 07:04:09 -0700"
Date: Mon, 14 Apr 2008 10:32:42 -0400
Message-ID: <2155.1208183562@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Darren Reed <darrenr+postgres@fastmail.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