Re: WIP checksums patch
От | jesper@krogh.cc |
---|---|
Тема | Re: WIP checksums patch |
Дата | |
Msg-id | aee8d8c0eb23f66c3b2d54eb0bfbaae4.squirrel@shrek.krogh.cc обсуждение исходный текст |
Ответ на | Re: WIP checksums patch (Jim Nasby <jim@nasby.net>) |
Список | pgsql-hackers |
> On 10/1/12 12:22 PM, Josh Berkus wrote: >>> >Perhaps we don't allow this to be turned per page, but rather per >>> >cluster, and per-cluster would require the entire cluster to be >>> >rewritten. >> We dicussed this last year, and options which require a total rewrite of >> the database in order to turn on the option were rejected as impractical >> for users. > > For whatever it's worth... we (and presumably others) still use londiste > (or Slony) as our upgrade path, so we could tolerate a cluster-wide > setting. We'd just set it when building new clusters via londiste and > forget about it. > > So I'd rather see this get in at a cluster level than not make it at all > while we wait for something better. Some still do dump/restore between major releases, so there it is also applicable. (and preferrable). I do know a lot of things had been discussed last year, an API I could easily imagine would work: ALTER TABLE <tablename> SET ENABLE_CHECKSUMMING=YES (would make the server do the checksums on all writes on table+indices going forward, here, verification of the checksums would still be enabled, but only on "already checksummed pages" ). ALTER TABLE <tablename> set VERIFY_CHECKSUM=YES (would cause the server to scan table and index, and rewrite the parts that hadn't an updated with a checksum already. Perhaps the names are not well-chosen, but it is based on the assumptions that check-summing overhead is measurable and it is thereby desireable to be able to dis/enable it on a per-table level. Then I could let my system go 6-12 months between the above two commands and the amount of rewrite would hopefully not require a rewrite of the entire 2.5TB of PGDATA. Jesper -- Jesper Krogh
В списке pgsql-hackers по дате отправления: