Re: read() returns ERANGE in Mac OS X

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: read() returns ERANGE in Mac OS X
Date: 2012-05-16 15:38:16
Message-ID: 1337182602-sup-8471@alvh.no-ip.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


Excerpts from Tom Lane's message of mié may 16 09:51:26 -0400 2012:
> Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> writes:
> > We just came across a situation where a corrupted HFS+ filesystem
> > appears to return ERANGE on a customer machine. Our first reaction was
> > to turn zero_damaged_pages on to allow taking a pg_dump backup of the
> > database, but surprisingly this does not work. A quick glance at the
> > code shows the reason:
> > ...
> > Note that zero_damaged_pages only enters the picture if it's a short
> > read, not if the read actually fails completely.
>
> > Is this by design, or is this just an oversight?
>
> 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 ...

Understood. This is a bit at odds with what the docs say about about
the feature though:

Detection of a damaged page header normally causes PostgreSQL to report an
error, aborting the current transaction. Setting zero_damaged_pages to on
causes the system to instead report a warning, zero out the damaged page in
memory, and continue processing. This behavior will destroy data, namely all
the rows on the damaged page. However, it does allow you to get past the error
and retrieve rows from any undamaged pages that might be present in the table.
It is useful for recovering data if corruption has occurred due to a hardware
or software error. You should generally not set this on until you have given up
hope of recovering data from the damaged pages of a table. Zeroed-out pages are
not forced to disk so it is recommended to recreate the table or the index
before turning this parameter off again. The default setting is off, and it can
only be changed by a superuser.
http://www.postgresql.org/docs/9.1/static/runtime-config-developer.html

Maybe I just need another setting, zero_pages_damaged_at_the_os_level or
something like that.

... just kidding.

--
Álvaro Herrera <alvherre(at)commandprompt(dot)com>
The PostgreSQL Company - Command Prompt, Inc.
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Fujii Masao 2012-05-16 15:49:37 Re: Strange issues with 9.2 pg_basebackup & replication
Previous Message Fujii Masao 2012-05-16 15:36:26 Re: Strange issues with 9.2 pg_basebackup & replication