X-Original-To: pgsql-admin-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5457D540C2 for ; Fri, 15 Apr 2005 17:55:35 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 57678-06 for ; Fri, 15 Apr 2005 20:55:33 +0000 (GMT) Received: from mailhost.intellivid.com (mailhost.intellivid.com [64.32.200.11]) by svr1.postgresql.org (Postfix) with ESMTP id B7393540C7 for ; Fri, 15 Apr 2005 17:55:32 -0300 (ADT) Received: from [192.168.2.68] (spectre.intellivid.com [192.168.2.68]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by newmail.intellivid.com (Postfix) with ESMTP id 5CCD2F1806A for ; Fri, 15 Apr 2005 16:55:32 -0400 (EDT) Subject: database corruption From: Ian Westmacott To: pgsql-admin@postgresql.org Content-Type: text/plain Message-Id: <1113598532.8214.175.camel@spectre.intellivid.com> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6 Date: Fri, 15 Apr 2005 16:55:32 -0400 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200504/208 X-Sequence-Number: 17221 For several weeks now we have been experiencing fairly severe database corruption upon clean reboot. It is very repeatable, and the corruption is of the following forms: ERROR: could not access status of transaction foo DETAIL: could not open file "bar": No such file or directory ERROR: invalid page header in block foo of relation "bar" ERROR: uninitialized page in block foo of relation "bar" At first, we believed this was related to XFS, and have been pursuing investigations along those lines. However, we have now experienced the exact same problem with JFS. Here are some details: - Postgres 7.4.2 - 2.6.6 kernel.org kernel - dedicated database partition - repeatable with XFS and JFS (have not seen on ext3) - repeatable with and without Linux software RAID 0 - repeatable with IDE and SATA - repeatable with and without fsync, and with fdatasync - repeatable on multiple systems I have two questions: - any known reason why this might be occurring? (we must have something wrong, for this high rate of severe error). - if I don't care about losing data, and am not interested in trying to recover anything, how can I arrange for Postgres to proceed normally? I know about zero_damaged_pages, but this doesn't help with missing transaction files and such. Is there any way to get Postgres to chuck anything bad and proceed? Thanks, --Ian