On May18, 2012, at 23:18 , Alvaro Herrera wrote:
> Excerpts from Florian Pflug's message of jue may 17 09:08:26 -0400 2012:
>> On May16, 2012, at 15:51 , Tom Lane wrote:
>
>>> 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.
>
> Seems to me that we could make zero_damaged_pages an enum. The default
> value of "on" would only catch truncated-away pages; another value would
> also capture kernel-level error conditions.
Yeah, an enum would be nicer than an additional GUC. I kinda keep forgetting
that we have those. Though to bikeshed, the GUC should probably be just called
'zero_pages' and take the values 'never', 'missing', 'unreadable' ;-)
> The thing is, once you start getting kernel-level errors you're pretty
> much screwed and there's no way to just recover whatever data is
> recoverable.
I thought your initial gripe was precisely that you got a kernel-level error,
yet the filesystem was still in pretty good shape?
Which actually seemed quite likely to me - the cause could be, for example,
simply a single bad block. Or a filesystem-level checksum error if you're using
a filesystem with built-in integrity checks.
best regards,
Florian Pflug