Re: read() returns ERANGE in Mac OS X

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

In response to

Responses

Browse pgsql-hackers by date

  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