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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
