On May16, 2012, at 15:51 , Tom Lane wrote:
> Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
>> We just came across a situation where a corrupted HFS+ filesystem
>> appears to return ERANGE on a customer machine. Our first reaction was
>> to turn zero_damaged_pages on to allow taking a pg_dump backup of the
>> database, but surprisingly this does not work. A quick glance at the
>> code shows the reason:
>> ...
>> Note that zero_damaged_pages only enters the picture if it's a short
>> read, not if the read actually fails completely.
>
>> Is this by design, or is this just an oversight?
>
> It is by design, in that the only contemplated case was truncated-away
> pages. I'm pretty hesitant to consider allowing arbitrary kernel errors
> to be ignored here …
Maybe we should have zero_missing_pages which would only zero on short reads,
and zero_damaged_pages which would zero on all IO errors?
Or we could have zero_damaged_pages zero only if reports EIO, and then add
any platform-specific additional error codes as we learn about them. ERANGE
on darwin would be the first such addition.
In any case, it seems to me that at least EIO should trigger zeroing, since
that is presumably what you'd get on a filesystem with integrated checksums
like ZFS.
best regards,
Florian Pflug