A heap page corruption is not very likely in PostgreSQL because of the
underlying page design. Not even on flakey hardware/ossoftware.
(I once read a page design note from pg 4 but don't exactly remember
were or when)
The point is, that the heap page is only modified in places that were
previously empty (except header). All previous row data stays exactly
in the same place. Thus if a page is only partly written
(any order of page segments) only a new row is affected. But those rows
will be fixed during redo anyway. The only source of serious problems is
thus a bogus write of a page segment (100 bytes ok 412 bytes chunk
actually written to disk), but this case is imho sufficiently guarded or at least
detected by disk hardware.
(I assume that the page header fits into one atomic block and has no problem
with beeing one step behind or ahead of redo).
I thus doubt that we really need "physical log" for heap pages in PostgreSQL
with the current non-overwrite smgr. If we could detect corruption in index pages
we would not need physical log at all, since an index can always be recreated.
What do you think ? I ask because "physical log" is a substantial amount of
additional IO that we imho only want if it is absolutely necessary.
Andreas
