> With a potential 10-20% overhead, I am unclear who would enable this at > initdb time.
People who know they have a chronic issue with bad disks/cards/drivers would. Or anyone with enough machines that IO corruption is an operational concern worth more than 10% overhead. Or, in a word: Heroku, Enova and Aster Data, by their own admission. This seems like a sufficiently rsignificant user group to make it worthwhile to get something in, as long as it's something we can build on. Also, Simon, Greg and I discussed this feature while at PyCon last week. We went over it to discuss whether the poor performance now was a permanent result of the checksum design, or whether it would be possible to improve performance in future versions of PostgreSQL without an incompatible change. We concluded that it would be possible to improve it substantially while using the same file & checksum format. Some of the performance improvements require finally doing something to clean up hint bits, though, so it's not something we want to do for 9.3 at this stage. As such, I'm recommending that we go ahead with committing this feature. > 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. "release early, release often". We just need to document that the feature has substantial performance overhead, and the limitations around it. Right now it's useful to a minority of our users, but in the future it can be made useful to a larger group. And, importantly, for that minority, there really is no other solution. > 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. Better get cracking, then! ;-) -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers