Re: Protecting against unexpected zero-pages: proposal

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Protecting against unexpected zero-pages: proposal
Дата
Msg-id 25661.1289233014@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Protecting against unexpected zero-pages: proposal  (Aidan Van Dyk <aidan@highrise.ca>)
Ответы Re: Protecting against unexpected zero-pages: proposal  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
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?  IT would mean writing to 2
> files but that shouldn't be a problem, because until the checkpoint is
> done (and thus both writes), the full-page-write in WAL is going to
> take precedence on recovery.

Doesn't seem like a terribly good design: damage to a checksum page
would mean that O(1000) data pages are now thought to be bad.

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.  This is the same
problem that index-only scans are hung up on, ie making the VM reliable.
I forget whether Heikki had a credible design sketch for making that
happen, but in any case it didn't look easy.
        regards, tom lane


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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: timestamp of the last replayed transaction
Следующее
От: Pavel Stehule
Дата:
Сообщение: Re: SQL2011 and writeable CTE