> 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
