Received: from maia.hub.org (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id C371D63402F for ; Sun, 28 Mar 2010 19:28:33 -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 03066-02-6 for ; Sun, 28 Mar 2010 22:28:12 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from ian.brad.office.comodo.net (brad.comodogroup.com [82.109.38.202]) by mail.postgresql.org (Postfix) with ESMTP id 7808E63354B for ; Sun, 28 Mar 2010 19:27:35 -0300 (ADT) Received: (qmail 10535 invoked from network); 28 Mar 2010 22:27:33 -0000 Received: from ian1.brad.office.comodo.net (HELO mail.brad.office.comodo.net) (192.168.0.201) by ian1.brad.office.comodo.net with SMTP; 28 Mar 2010 22:27:33 -0000 Received: from 192.168.22.137 (SquirrelMail authenticated user mikew) by mail.brad.office.comodo.net with HTTP; Sun, 28 Mar 2010 23:27:33 +0100 Message-ID: <719e433b1c118d4d8de72f171199678a.squirrel@mail.brad.office.comodo.net> In-Reply-To: <4588.1269805790@sss.pgh.pa.us> References: <201003281841.41865.mike.williams@comodo.com> <25082.1269800427@sss.pgh.pa.us> <3c7898fc579b37bfec2f5ff971df7532.squirrel@mail.brad.office.comodo.net> <4588.1269805790@sss.pgh.pa.us> Date: Sun, 28 Mar 2010 23:27:33 +0100 Subject: Re: ERROR: could not open segment 1 of relation 1663/743352/743420 (target block 6407642): No such file or directory From: "Mike Williams" To: "Tom Lane" Cc: pgsql-admin@postgresql.org User-Agent: SquirrelMail/1.4.19 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.855 tagged_above=-10 required=5 tests=AWL=0.745, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201003/215 X-Sequence-Number: 34014 On Sun, March 28, 2010 8:49 pm, Tom Lane wrote: >> 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? We do have a test system, and the only significant difference from production is the kernel. Test are para-virt VMs with "regular" kernels, production are real machines with hardened kernels (grsec+pax). I got prod onto a regular kernel and nothing in nearly an hour. 8.3.5 has worked forever and a day on this type of setup. -- Mike Williams