On 3/6/13 1:14 PM, Josh Berkus wrote:
There may be good reasons to reject this patch. Or there may not.
But I completely disagree with the idea that asking them to solve the
problem at the filesystem level is sensible.
Yes, can we get back to the main issues with the patch?
1) argument over whether the checksum is sufficient to detect most
errors, or if it will give users false confidence.
2) performance overhead.
Based on Smith's report, I consider (2) to be a deal-killer right now.
The level of overhead reported by him would prevent the users I work
with from ever employing checksums on production systems.
FWIW, the write workload most likely wouldn't be a problem for us. I am
concerned about the reported 24-32% hit when reading back in from FS cache...
that might kill this for us.
I'm working on doing a test to see how bad it actually is for us... but getting
stuff like that done at work is like pulling teeth, so we'll see...
Specifically, the writing checksums for a read-only query is a defect I
think is prohibitively bad. When we first talked about this feature for
9.2, we were going to exclude hint bits from checksums, in order to
avoid this issue; what happened to that?
(FWIW, I still support the idea of moving hint bits to a separate
filehandle, as we do with the FSM, but clearly that's not happening for
9.3 ...)
+1
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
