| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | Jim Nasby <jim(at)nasby(dot)net> |
| Cc: | Simon Riggs <simon(at)2ndquadrant(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, David Fetter <david(at)fetter(dot)org>, Stephen Frost <sfrost(at)snowman(dot)net>, Aidan Van Dyk <aidan(at)highrise(dot)ca>, Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-hackers(at)postgresql(dot)org, Greg Smith <greg(at)2ndQuadrant(dot)com>, Koichi Suzuki <koichi(dot)szk(at)gmail(dot)com> |
| Subject: | Re: Page Checksums |
| Date: | 2012-01-10 08:04:06 |
| Message-ID: | 4F0BF0F6.1080704@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 10.01.2012 02:12, Jim Nasby wrote:
> Filesystem CRCs very likely will not happen to data that's in the cache. For some users, that's a huge amount of data to leave un-protected.
You can repeat that argument ad infinitum. Even if the CRC covers all
the pages in the OS buffer cache, it still doesn't cover the pages in
the shared_buffers, CPU caches, in-transit from one memory bank to
another etc. You have to draw the line somewhere, and it seems
reasonable to draw it where the data moves between long-term storage,
ie. disk, and RAM.
> Filesystem bugs do happen... though presumably most of those would be caught by the filesystem's CRC check... but you never know!
Yeah. At some point we have to just have faith on the underlying system.
It's reasonable to provide protection or make recovery easier from bugs
or hardware faults that happen fairly often in the real world, but a
can't-trust-no-one attitude is not very helpful.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2012-01-10 08:48:30 | Re: Sending notifications from the master to the standby |
| Previous Message | Peter Geoghegan | 2012-01-10 06:48:11 | Re: Progress on fast path sorting, btree index creation time |