Re: Enabling Checksums - Mailing list pgsql-hackers
From | Bruce Momjian |
---|---|
Subject | Re: Enabling Checksums |
Date | |
Msg-id | 20130318175258.GB16641@momjian.us Whole thread Raw |
In response to | Re: Enabling Checksums (Greg Smith <greg@2ndQuadrant.com>) |
Responses |
Re: Enabling Checksums
(Pavel Stehule <pavel.stehule@gmail.com>)
Re: Enabling Checksums (Simon Riggs <simon@2ndQuadrant.com>) Re: Enabling Checksums (Stephen Frost <sfrost@snowman.net>) Re: Enabling Checksums (Josh Berkus <josh@agliodbs.com>) Re: Enabling Checksums (Jeff Davis <pgsql@j-davis.com>) Re: Enabling Checksums (Greg Smith <greg@2ndQuadrant.com>) Re: Enabling Checksums (Greg Stark <stark@mit.edu>) Re: Enabling Checksums (Bruce Momjian <bruce@momjian.us>) Re: Enabling Checksums (Greg Smith <greg@2ndQuadrant.com>) Re: Enabling Checksums (Greg Smith <greg@2ndQuadrant.com>) |
List | pgsql-hackers |
On Sun, Mar 17, 2013 at 05:50:11PM -0700, Greg Smith wrote: > As long as the feature is off by default, so that people have to > turn it on to hit the biggest changed code paths, the exposure to > potential bugs doesn't seem too bad. New WAL data is no fun, but > it's not like this hasn't happened before. With a potential 10-20% overhead, I am unclear who would enable this at initdb time. I assume a user would wait until they suspected corruption to turn it on, and because it is only initdb-enabled, they would have to dump/reload their cluster. The open question is whether this is a usable feature as written, or whether we should wait until 9.4. pg_upgrade can't handle this because the old/new clusters would have the same catalog version number and the tablespace directory names would conflict. Even if they are not using tablespaces, the old heap/index files would not have checksums and therefore would throw an error as soon as you accessed them. In fact, this feature is going to need pg_upgrade changes to detect from pg_controldata that the old/new clusters have the same checksum setting. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + It's impossible for everything to be true. +
pgsql-hackers by date: