From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com> |
Subject: | Re: Updating FSM on recovery |
Date: | 2008-10-30 10:52:50 |
Message-ID: | 87iqracq2l.fsf@oxford.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> 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!
From | Date | Subject | |
---|---|---|---|
Next Message | Markus Wanner | 2008-10-30 11:20:19 | Re: Postgres-R pacth |
Previous Message | Zdenek Kotala | 2008-10-30 10:39:45 | Question about GetAttributeByNum(Name) ExecQual.c |