On Mon, Jan 23, 2017 at 5:47 PM, Stephen Frost <sfr...@snowman.net> wrote: >> Perhaps I've missed the point entirely, but, I have to ask: How could >> there ever be false positives? With checksums, false positives are >> simply not allowed. Therefore, there cannot be a false positive, >> unless we define checksums as a mechanism that should only find >> problems that originate somewhere at or below the filesystem. We >> clearly have not done that, so ISTM that checksums could legitimately >> find bugs in the checksum code. I am not being facetious. > > I'm not sure I'm following your question here. A false positive would > be a case where the checksum code throws an error on a page whose > checksum is correct, or where the checksum has failed but nothing is > actually wrong/different on the page.
I thought that checksums went in in part because we thought that there was some chance that they'd find bugs in Postgres. I was under the impression that that was at least a secondary goal of checksums. > As for the purpose of checksums, it's exactly to identify cases where > the page has been changed since we wrote it out, due to corruption in > the kernel, filesystem, storage system, etc. As we only check them when > we read in a page and calculate them when we go to write the page out, > they aren't helpful for shared_buffers corruption, generally speaking. I'd have guessed that they might catch a bug in recovery itself, even when the filesystem maintains the guarantees Postgres requires. In any case, it seems exceedingly unlikely that the checksum code itself would fail. -- Peter Geoghegan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
