Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id A21A364FE67 for ; Thu, 30 Oct 2008 07:53:00 -0300 (ADT) Received: from postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 74536-10 for ; Thu, 30 Oct 2008 07:52:57 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.191]) by postgresql.org (Postfix) with ESMTP id C91EA64FD48 for ; Thu, 30 Oct 2008 07:52:56 -0300 (ADT) Received: by nf-out-0910.google.com with SMTP id c7so238107nfi.23 for ; Thu, 30 Oct 2008 03:52:54 -0700 (PDT) Received: by 10.210.22.16 with SMTP id 16mr11505121ebv.69.1225363974523; Thu, 30 Oct 2008 03:52:54 -0700 (PDT) Received: from oxford.xeocode.com.enterprisedb.com ([82.16.16.210]) by mx.google.com with ESMTPS id i4sm6671775nfh.1.2008.10.30.03.52.52 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 30 Oct 2008 03:52:53 -0700 (PDT) To: Heikki Linnakangas Cc: Tom Lane , PostgreSQL-development , Simon Riggs Subject: Re: Updating FSM on recovery In-Reply-To: <490972E5.1010605@enterprisedb.com> (Heikki Linnakangas's message of "Thu\, 30 Oct 2008 10\:40\:05 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.1 (gnu/linux) X-Draft-From: ("nnimap+imap.gmail.com:HACKERS" 47488) References: <49072021.7010801@enterprisedb.com> <24334.1225205478@sss.pgh.pa.us> <49074779.2080309@enterprisedb.com> <9672.1225215390@sss.pgh.pa.us> <49085327.5010608@enterprisedb.com> <11303.1225283814@sss.pgh.pa.us> <490972E5.1010605@enterprisedb.com> From: Gregory Stark Organization: EnterpriseDB Date: Thu, 30 Oct 2008 10:52:50 +0000 Message-ID: <87iqracq2l.fsf@oxford.xeocode.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests=none X-Spam-Level: X-Archive-Number: 200810/1567 X-Sequence-Number: 126584 Heikki Linnakangas writes: > Hmm. I think an enum is better than a bitmask here. At the moment, we need > three different modes of operation: > 1. Read the page as usual, throw an error on corrupted page (ReadBuffer()) > 2. Read the page, zero page on corruption (this is new) Is this new? Would it make sense for zero_damaged_pages to use this? Perhaps the enum should have an option to error on damaged pages, warn and zero damaged pages, or just zero damaged pages. We might also want different behaviour for pages for which the crc doesn't match versus pages that have nonsensical page headers. > 3. Don't read the page from disk, just allocate a buffer. (ReadOrZeroBuffer()) -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Ask me about EnterpriseDB's Slony Replication support!