To: Darren Reed <darrenr@fastmail.net>
cc: pgsql-admin@postgresql.org
Subject: Re: postgres 8.2.6 core dump when initialising. 
In-reply-to: <4804CC1F.10204@fastmail.net> 
References: <4802F108.2090709@fastmail.net> <1071.1208179948@sss.pgh.pa.us>
	<48036459.7040503@fastmail.net> <2155.1208183562@sss.pgh.pa.us>
	<4803723E.9030106@fastmail.net> <4429.1208188633@sss.pgh.pa.us>
	<4804CC1F.10204@fastmail.net>
Comments: In-reply-to Darren Reed <darrenr@fastmail.net>
	message dated "Tue, 15 Apr 2008 08:39:11 -0700"
Date: Tue, 15 Apr 2008 12:01:56 -0400
Message-ID: <15514.1208275316@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Darren Reed <darrenr@fastmail.net> writes:
> Tom Lane wrote:
>> BTW, could you send me the contents of file 24579 in that database
>> (dump it with pg_filedump, same as before)?  According to your dump
>> that's the reindexed version of pg_class_oid_index, and I'm curious
>> to see whether it contains index entries pointing at block 7 of
>> pg_class.  If my theory is right then it will.

> Attached.

Sure enough, there are 26 index entries referencing block 7, which
matches the number of updates into that block that seemed to have
occurred according to pg_class.  So those updates definitely happened,
and then *something* made block 7 go away.

What's the platform here --- what kernel, what version exactly,
what hardware and disk subsystem?  I think your problem is somewhere
in there ...

			regards, tom lane