Re: 16-bit page checksums for 9.2
| От | Robert Haas |
|---|---|
| Тема | Re: 16-bit page checksums for 9.2 |
| Дата | |
| Msg-id | CA+TgmobV-nZmC7y5=ED099Qoc_jAPDCV7sQ+w5OiH4UfeDUJUg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: 16-bit page checksums for 9.2 (Simon Riggs <simon@2ndQuadrant.com>) |
| Список | pgsql-hackers |
On Sun, Dec 25, 2011 at 5:08 AM, Simon Riggs <simon@2ndquadrant.com> wrote: > On Sat, Dec 24, 2011 at 8:06 PM, Greg Stark <stark@mit.edu> wrote: >> On Sat, Dec 24, 2011 at 4:06 PM, Simon Riggs <simon@2ndquadrant.com> wrote: >>> Checksums merely detect a problem, whereas FPWs correct a problem if >>> it happens, but only in crash situations. >>> >>> So this does nothing to remove the need for FPWs, though checksum >>> detection could be used for double write buffers also. >> >> This is missing the point. If you have a torn page on a page that is >> only dirty due to hint bits then the checksum will show a spurious >> checksum failure. It will "detect" a problem that isn't there. > > It will detect a problem that *is* there, but one you are classifying > it as a non-problem because it is a correctable or acceptable bit > error. I don't agree with this. We don't WAL-log hint bit changes precisely because it's OK if they make it to disk and it's OK if they don't. Given that, I don't see how we can say that writing out only half of a page that has had hint bit changes is a problem. It's not. (And if it is, then we ought to WAL-log all such changes regardless of whether CRCs are in use.) -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: