From: | Alvaro Herrera <alvherre(at)commandprompt(dot)com> |
---|---|
To: | Florian Pflug <fgp(at)phlo(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: read() returns ERANGE in Mac OS X |
Date: | 2012-05-18 21:18:57 |
Message-ID: | 1337375767-sup-8837@alvh.no-ip.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2012-05-18 21:50:31 | Re: psql bug |
Previous Message | Stephen Frost | 2012-05-18 21:15:14 | Re: Pre-alloc ListCell's optimization |