Re: read() returns ERANGE in Mac OS X
От | Alvaro Herrera |
---|---|
Тема | Re: read() returns ERANGE in Mac OS X |
Дата | |
Msg-id | 1337375767-sup-8837@alvh.no-ip.org обсуждение исходный текст |
Ответ на | Re: read() returns ERANGE in Mac OS X (Florian Pflug <fgp@phlo.org>) |
Ответы |
Re: read() returns ERANGE in Mac OS X
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: