Received: from maia.hub.org (unknown [200.46.208.211])
	by mail.postgresql.org (Postfix) with ESMTP id 537C6633A27
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 28 Mar 2010 17:19:35 -0300 (ADT)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.208.211]) (amavisd-maia,
	port 10024) with ESMTP id 83832-01-10
	for <pgsql-admin-postgresql.org@mail.postgresql.org>;
	Sun, 28 Mar 2010 20:19:18 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130])
	by mail.postgresql.org (Postfix) with ESMTP id ADCFC6369F0
	for <pgsql-admin@postgresql.org>; Sun, 28 Mar 2010 16:49:57 -0300 (ADT)
Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1])
	by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o2SJnpe0004589;
	Sun, 28 Mar 2010 15:49:51 -0400 (EDT)
To: "Mike Williams" <mike.williams@comodo.com>
cc: pgsql-admin@postgresql.org
Subject: Re: ERROR: could not open segment 1 of relation 1663/743352/743420
	(target block 6407642): No such file or directory
In-reply-to: 
 <3c7898fc579b37bfec2f5ff971df7532.squirrel@mail.brad.office.comodo.net>
References: <201003281841.41865.mike.williams@comodo.com>
	<25082.1269800427@sss.pgh.pa.us>
	<3c7898fc579b37bfec2f5ff971df7532.squirrel@mail.brad.office.comodo.net>
Comments: In-reply-to "Mike Williams" <mike.williams@comodo.com>
	message dated "Sun, 28 Mar 2010 20:29:52 +0100"
Date: Sun, 28 Mar 2010 15:49:50 -0400
Message-ID: <4588.1269805790@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-2.463 tagged_above=-10 required=5 tests=AWL=0.136,
	BAYES_00=-2.599
X-Spam-Level: 
X-Archive-Number: 201003/213
X-Sequence-Number: 34012

"Mike Williams" <mike.williams@comodo.com> writes:
> The "target block" stays the same for extended periods, but does change.

Fascinating.  Don't know what it means, but it's fascinating.

> Where does the 1663 number come from?
> <datadir/base>/743352/743420 is a real file, but I don't have any file 1663.

1663 is the OID of the pg_default tablespace; that's never going to
change unless you move the table to a non-default tablespace.

> The server is Gentoo, and I don't have an identical server to use. This
> machines HA partner is staying at 8.3.5 until we're completely and
> entirely sure 8.3.10 works right.

I wasn't really suggesting that you need an *identical* machine.  If
this is a software problem, as seems moderately likely at this point,
it should be possible to reproduce it on a different machine.  Even more
to the point, it's going to be difficult to find the problem without
tracing through the fault case with a debugger --- which isn't something
you're going to want to do on a production server.  Have you got a test
machine you can load the data onto?  Preferably one you could give a PG
developer access to?

<aside>Using gentoo for production servers is generally viewed with
suspicion around here; gentoo is a fine distro but, um, not especially
focused on stability.  Still, there's no obvious reason to blame this on
the distro.</aside>

			regards, tom lane