Excerpts from Florian Pflug's message of sáb may 19 03:48:51 -0400 2012: > > On May18, 2012, at 23:18 , Alvaro Herrera wrote: > > Excerpts from Florian Pflug's message of jue may 17 09:08:26 -0400 2012:
> > 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' ;-) Sounds reasonable to me .. > > 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? Uhm. I'm not really sure what's the actual problem, but I think it is precisely a corrupted filesystem. > 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. I guess ERANGE is the sort of thing that's not quite expected here -- I mean you might get EIO if there's an I/O problem such as a checksum error, but ERANGE suggests to me that the kernel might be leaking some internal error that's not supposed to be thrown to the user. In any case I don't think we can distinguish kernel-level problems such as this one, from filesystem level problems. I mean, they all come from the kernel, as far as we're concerned. -- Álvaro Herrera <alvhe...@commandprompt.com> The PostgreSQL Company - Command Prompt, Inc. PostgreSQL Replication, Consulting, Custom Development, 24x7 support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
