"Tom Lane" <tgl@sss.pgh.pa.us> writes:
> "Simon Riggs" <simon@2ndquadrant.com> writes:
>> COPY XLogInsert() #1 on oprofile results at 17% CPU
>> (full_page_writes = on)
>
> But what portion of that is actually CRC-related? XLogInsert does quite
> a lot.
>
> Anyway, I can't see degrading the reliability of the system for a gain
> in the range of a few percent, which is the most that we'd be likely
> to get here ... for a factor of two or more, maybe people would be
> willing to take a risk.
Well the problem with that is when you have dozens of 1% improvements which
are additive and the net negative effects aren't additive. Since we can't
quantify the effect on reliability here it's hard to tell if that's the case.
What did you think about protecting against torn writes using id numbers every
512 bytes. That "improves" the reliability of the system in that it detects
torn writes 100% of the instead of just (2^32-1)/2^32 (or 99.99999998%) of the
time. (which poking a hole in the CRC mechanism would reduce to (2^31-1)/2^31
(or 99.99999995%)).
I don't think either of those percentages are significant. If you crash your
system once a day and always get a torn WAL page you're still far more likely
to still get corrupted data due to cosmic rays long before you get corrupted
data due to mistakenly applying a torn page from WAL.
But if we can save CPU on every WAL write while not harming reliability (in
fact increasing it, albeit insignificantly) why not?
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com