Re: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Protecting against unexpected zero-pages: proposal
Дата
Msg-id 26131.1289235642@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Protecting against unexpected zero-pages: proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Protecting against unexpected zero-pages: proposal  (Greg Stark <gsstark@mit.edu>)
Список pgsql-hackers
I wrote:
> Aidan Van Dyk <aidan@highrise.ca> writes:
>> Getting back to the checksum debate (and this seems like a
>> semi-version of the checksum debate), now that we have forks, could we
>> easily add block checksumming to a fork?

> More generally, this re-opens the question of whether data in secondary
> forks is authoritative or just hints.  Currently, we treat it as just
> hints, for both FSM and VM, and thus sidestep the problem of
> guaranteeing its correctness.  To use a secondary fork for checksums,
> you'd need to guarantee correctness of writes to it.

... but wait a minute.  What if we treated the checksum as a hint ---
namely, on checksum failure, we just log a warning rather than doing
anything drastic?  A warning is probably all you want to happen anyway.

A corrupted page of checksums would then show up as warnings for most or
all of a range of data pages, and it'd be pretty obvious (if the data
seemed OK) where the failure had been.

So maybe Aidan's got a good idea here.  It would sure be a lot easier
to shoehorn checksum checking in as an optional feature if the checksums
were kept someplace else.
        regards, tom lane


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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: How to share the result data of separated plan
Следующее
От: Marko Tiikkaja
Дата:
Сообщение: Re: How to share the result data of separated plan