From: | Jim Nasby <jim(at)nasby(dot)net> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Enabling Checksums |
Date: | 2013-03-07 00:17:32 |
Message-ID: | 5137DC9C.202@nasby.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Lawrence Barwick | 2013-03-07 00:27:06 | Small patch for "CREATE TRIGGER" documentation |
Previous Message | Jim Nasby | 2013-03-07 00:14:09 | Re: Enabling Checksums |