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 3AED4D1B25F for ; Thu, 22 Jul 2004 15:24:09 -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 83258-06 for ; Thu, 22 Jul 2004 18:24:09 +0000 (GMT) Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by svr1.postgresql.org (Postfix) with ESMTP id C920AD1B211 for ; Thu, 22 Jul 2004 15:24:06 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.12.11/8.12.11) with ESMTP id i6MIO74k011037; Thu, 22 Jul 2004 14:24:07 -0400 (EDT) To: Ian Burrell Cc: pgsql-admin@postgresql.org Subject: Re: Invalid page header In-reply-to: <40FFF98C.3000309@rentrak.com> References: <40FFF98C.3000309@rentrak.com> Comments: In-reply-to Ian Burrell message dated "Thu, 22 Jul 2004 10:29:48 -0700" Date: Thu, 22 Jul 2004 14:24:07 -0400 Message-ID: <11036.1090520647@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.0 tagged_above=0.0 required=5.0 tests= X-Spam-Level: X-Archive-Number: 200407/252 X-Sequence-Number: 14320 Ian Burrell writes: > I get the following error message when doing a select on a table: > ERROR: invalid page header in block 295 of relation "reported_titles" > How do I fix this corruption? You can zap just the failed block by turning on "zero_damaged_pages"; that will at least allow you to recover the rest of the table. If you want to try harder, you could look at the damaged page with pg_filedump (http://sources.redhat.com/rhdb/) or a similar tool and try to intuit how to fix it manually. > What could cause the corruption? We are using custom C code. Could > bugs in this be causing it? Or is hardware problems more likely? Hmm. A scribble-on-memory kind of bug could cause this, but in my experience it's unusual for coding errors to trash the disk buffers --- that's a relatively small part of your address space, and usually a memory clobber will crash the backend elsewhere before it hits a disk buffer. (BTW, one reason we force a database restart after a backend crash is in hopes of not letting any such clobber make it to disk. The contents of shared disk buffers are simply thrown away in a restart.) It would probably be worth your while to look at the damaged page with pg_filedump before you zap it. The symptoms of hardware misfeasance and software errors are enough different that you can often tell which theory to believe by examining the bits. regards, tom lane