"Tom Lane" <[EMAIL PROTECTED]> writes:

> Oh, sorry, had the wrong context in mind.  I'm still not very impressed
> with the idea --- a CRC check will catch many kinds of problems, whereas
> this approach catches exactly one kind of problem.

Well in fairness I tossed in a throwaway comment at the end of that email
about heap pages. I'll do the same here since I can't resist. But the main
thread here is about xlog really.

It just seems to me like it's better to target each problem with a solution
that addresses it directly than have one feature that we hope hope addresses
them all more or less.

Having a CRC in WAL but not in the heap seems kind of pointless. If your
hardware is unreliable the corruption could anywhere. Depending on it to solve
multiple problems means we can't offer the option to disable it because it
would affect other things as well.

What I would like to see is a CRC option that would put CRC checks in every
disk page whether heap, index, WAL, control file, etc. I think we would
default that to off to match our current setup most closely.

Separately we would have a feature in WAL to detect torn pages so that we can
reliably detect the end of valid WAL. That would have to always be on. But
having it as a separate feature means the CRC could be optional.

Also, incidentally like I mentioned in my previous email, we could do the torn
page detection in heap pages too by handling it in the smgr using
readv/writev. No copies, no corrupted datums. Essentially the tags would be
inserted on the fly as the data was copied into kernel space.

  Gregory Stark
  EnterpriseDB          http://www.enterprisedb.com

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to