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 <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
