
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

Fri, 15 Dec 2000 12:41:59 +0100
Zeugswetter Andreas SB <ZeugswetterA@wien.spardat.at>
heap page corruption not easy