Re: Page Checksums

Поиск
Список
Период
Сортировка
От Christopher Browne
Тема Re: Page Checksums
Дата
Msg-id CAFNqd5WxiHtoF1DpdJ+nGzi=UXdsb0jXA90Jt2doX4aH5doArQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Page Checksums  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Page Checksums  (Alvaro Herrera <alvherre@commandprompt.com>)
Re: Page Checksums  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Dec 20, 2011 at 8:36 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Mon, Dec 19, 2011 at 2:44 PM, Kevin Grittner
> <Kevin.Grittner@wicourts.gov> wrote:
>> I was thinking that we would warn when such was found, set hint bits
>> as needed, and rewrite with the new CRC.  In the unlikely event that
>> it was a torn hint-bit-only page update, it would be a warning about
>> something which is a benign side-effect of the OS or hardware crash.
>
> But that's terrible.  Surely you don't want to tell people:
>
> WARNING:  Your database is corrupted, or maybe not.  But don't worry,
> I modified the data block so that you won't get this warning again.
>
> OK, I guess I'm not sure that you don't want to tell people that.  But
> *I* don't!

This seems to be a frequent problem with this whole "doing CRCs on pages" thing.

It's not evident which problems will be "real" ones.  And in such
cases, is the answer to turf the database and recover from backup,
because of a single busted page?  For a big database, I'm not sure
that's less scary than the possibility of one page having a
corruption.
--
When confronted by a difficult problem, solve it by reducing it to the
question, "How would the Lone Ranger handle this?"


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe
Следующее
От: Simon Riggs
Дата:
Сообщение: Re: Pause at end of recovery