On Tue, Jan 24, 2017 at 10:26 AM, Stephen Frost <sfr...@snowman.net> wrote: > * Tom Lane (t...@sss.pgh.pa.us) wrote: >> >> I don't recall ever seeing a checksum failure on a Heroku Postgres >> >> database, > > Not sure how this part of that sentence was missed: > > ----- > ... even though they were enabled as soon as the feature became > available. > ----- > > Which would seem to me to say "the code's been running for a long time > on a *lot* of systems without throwing a false positive or surfacing a > bug."
I am reading that similarly to what Tom is seeing: enabling it has proved Heroku that it did not catch problems in years, meaning that the performance cost induced by enabling it has paid nothing in practive, except the insurance to catch up problems should they happen. > Given your up-thread concerns that enabling checksums could lead to > false positives and might surface bugs, that's pretty good indication > that those concerns are unfounded. FWIW, I have seen failures that could have been as hardware failures or where enabling checksums may have helped, but they were on pre-9.3 instances. Now there is a performance penalty in enabling them, but it solely depends on the page eviction from shared buffers, which is pretty high for some load patterns I work with, still even with that we saw a 1~2% output penalty in measurements. Perhaps not everybody would like to pay this price. FWIW, we are thinking about paying it as VMs are more sensitive to vmdk-like class of bugs. I am not sure that everybody would like to pay that. By seeing this thread -hackers likely are fine with the cost induced. -- Michael -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
