> 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
