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.
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.
--
Álvaro Herrera <alvherre@commandprompt.com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
