On Sun, Dec 18, 2011 at 7:51 PM, Jesper Krogh <jes...@krogh.cc> wrote: > I dont know if it would be seen as a "half baked feature".. or similar, > and I dont know if the hint bit problem is solvable at all, but I could > easily imagine checksumming just "skipping" the hit bit entirely.
That was one approach discussed. The problem is that the hint bits are currently in each heap tuple header which means the checksum code would have to know a fair bit about the structure of the page format. Also the closer people looked the more hint bits kept turning up because the coding pattern had been copied to other places (the page header has one, and index pointers have a hint bit indicating that the target tuple is deleted, etc). And to make matters worse skipping individual bits in varying places quickly becomes a big consumer of cpu time since it means injecting logic into each iteration of the checksum loop to mask out the bits. So the general feeling was that we should move all the hint bits to a dedicated part of the buffer so that they could all be skipped in a simple way that doesn't depend on understanding the whole structure of the page. That's not conceptually hard, it's just a fair amount of work. I think that's where it was left off. There is another way to look at this problem. Perhaps it's worth having a checksum *even if* there are ways for the checksum to be spuriously wrong. Obviously having an invalid checksum can't be a fatal error then but it might still be useful information. Rright now people don't really know if their system can experience torn pages or not and having some way of detecting them could be useful. And if you have other unexplained symptoms then having checksum errors might be enough evidence that the investigation should start with the hardware and get the sysadmin looking at hardware logs and running memtest sooner. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
