Received: from localhost (postgresql.org [64.49.215.8]) by postgresql.org (Postfix) with ESMTP id 60588475B8F for ; Wed, 4 Sep 2002 00:30:53 -0400 (EDT) Received: from sss.pgh.pa.us (unknown [192.204.191.242]) by postgresql.org (Postfix) with ESMTP id CD630475AFA for ; Wed, 4 Sep 2002 00:30:52 -0400 (EDT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.5/8.12.5) with ESMTP id g844UbZM024486; Wed, 4 Sep 2002 00:30:37 -0400 (EDT) To: Jean-Denis Girard Cc: pgsql-interfaces@postgresql.org Subject: Re: Fatal error In-reply-to: <3D75818D.9020909@esoft.pf> References: <3D75818D.9020909@esoft.pf> Comments: In-reply-to Jean-Denis Girard message dated "Tue, 03 Sep 2002 17:44:13 -1000" Date: Wed, 04 Sep 2002 00:30:37 -0400 Message-ID: <24485.1031113837@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by AMaViS new-20020517 X-Archive-Number: 200209/26 X-Sequence-Number: 3087 Jean-Denis Girard writes: > Last tuesday I upgraded a production DB from 7.1 to 7.2. 7.2? I'd hope you went to 7.2.2, or at least 7.2.1. > FATAL 2: open of /var/lib/pgsql/data/pg_clog/0323 failed: No such file > or directory This message implies a bad xmin or xmax field in a stored tuple. We've seen a number of reports of similar failures, but so far the evidence has pointed to hardware failures rather than a software problem --- corrupted data on disk would usually trigger this kind of failure before anything else, so the particular error message doesn't seem very significant. > Don't know what to do and any help will be welcome. I can also provide > more specific information if needed. You should probably first try some hardware diagnostics like "memtest86" and "badblocks". I don't want to sound like I'm dismissing the possibility that it's a Postgres bug. It could be ... but without more evidence there's not much I can do to poke into it. regards, tom lane