Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, May 21, 2012 at 12:43 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Hm? zero_damaged_pages doesn't cause the buffer to be marked dirty,
>> so I dunno where these alleged writes are coming from.
> I'm not sure either, but I'm pretty sure I've seen at least one case
> where turning it on caused a whole lotta data to disappear.
[ thinks about that for awhile... ] The only plausible way for a zeroed
heap page to be silently overwritten by the system is if lazy_scan_heap()
reclaims it for re-use during an autovacuum. I was going to say that
autovacuum.c is careful to force zero_damaged_pages OFF to forestall
exactly this scenario, but on reflection I realize there is a hole in
that defense: the broken-on-disk page could be read in by some other
backend that has zero_damaged_pages ON, then left in shared buffers,
and then an autovacuum scan could find it and reclaim it.
I wonder whether we should dedicate a buffer status bit to show that
the buffer has been zeroed by zero_damaged_pages and thus doesn't
reflect what's on disk. Then we could teach autovacuum to not overwrite
such pages. On the other hand, such an approach would mean that you
couldn't use vacuum to forcibly clean up broken pages, so while this
might be "safer" it's not clear it makes things more useful.
regards, tom lane