Enabling Checksums

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Enabling Checksums
Дата
Msg-id 1352422901.31259.28.camel@sussancws0025
обсуждение исходный текст
Ответы Re: Enabling Checksums  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Re: Enabling Checksums  (Amit Kapila <amit.kapila@huawei.com>)
Re: Enabling Checksums  (Jesper Krogh <jesper@krogh.cc>)
Re: Enabling Checksums  (Markus Wanner <markus@bluegap.ch>)
Re: Enabling Checksums  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
As I understand it, the main part of the remaining work to be done for
the checksums patch (at least the first commit) is to have a better way
to enable/disable them.

For the sake of simplicity (implementation as well as usability), it
seems like there is agreement that checksums should be enabled or
disabled for the entire instance, not per-table.

I don't think a GUC entirely makes sense (in its current form, anyway).
We basically care about 3 states: 1. Off: checksums are not written, nor are they verified. Pages that
are newly dirtied have the checksum information in the header cleared. 2. Enabling: checksums are written for every
dirtypage, but only
 
verified for pages where the checksum is present (as determined by
information in the page header). 3. On: checksums are written for every dirty page, and verified for
every page that's read. If a page does not have a checksum, it's
corrupt.

Does it make sense to store this information in pg_control? That doesn't
require adding any new file, and it has the benefit that it's already
checksummed. It's available during recovery and can be made available
pretty easily in the places where we write data.

And the next question is what commands to add to change state. Ideas:
  CHECKSUMS ENABLE; -- set state to "Enabling"  CHECKSUMS DISABLE; -- set state to "Off"

And then to get to the "On" state, you have to run a system-wide VACUUM
while in the "Enabling" state. Or, if the above syntax causes problems,
we can make all of these into VACUUM options.

Thoughts?

Regards,Jeff Davis  




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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Further pg_upgrade analysis for many tables
Следующее
От: Tom Lane
Дата:
Сообщение: Re: AutoVacuum starvation from sinval messages