Message-ID: <524EF280.5040502@pasteleros.org.ar>
Date: Fri, 04 Oct 2013 13:53:20 -0300
From: Alejandro Brust <alejandrob@pasteleros.org.ar>
Reply-To: alejandrob@pasteleros.org.ar
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64;
 rv:17.0) Gecko/20130503 Thunderbird/17.0.5
MIME-Version: 1.0
To: pgsql-admin@postgresql.org
Subject: Re: ERROR: could not open file "base/125542/12631" Corruption?
References: 
 <CAB9893jR-_zaRxeRc0b4rapWLa-M-=Z-vSKt-vxD5uOhFs-z9w@mail.gmail.com>
In-Reply-To: 
 <CAB9893jR-_zaRxeRc0b4rapWLa-M-=Z-vSKt-vxD5uOhFs-z9w@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------070306080302000300010207"
Precedence: bulk
Sender: pgsql-admin-owner@postgresql.org

This is a multi-part message in MIME format.
--------------070306080302000300010207
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit


El 04/10/2013 11:40, Mike Broers escribió:
> Hello, our postgresql 9.2.4 qa database (thankfully its just qa) seems
> to be hosed.  
>
> Starting at around 3:39am last night I started seeing errors about
> missing files and now I cannot run a pgdump or a vacuum without it
> complaining about files that it cannot find with errors like this:
> ERROR: could not open file "base/125542/12631". When I check the
> filesystem the files are indeed not there.  The 1am regular vacuum
> completed and its log is clean.  The postgres log is clean before
> these errors occurred.
>
> Since this is qa we do not perform backups, and the solution if we
> cannot repair the problem will be to create a fresh qa server but I am
> intrigued about how to determine the source of the problem and the
> extent of the problem.  
>
> Is there a way to force vacuum to continue on errors or an alternate
> way to help determine all the missing files?  
>
> It might be totally unrelated, but yesterday morning on this qa server
> I stopped postgres, and created a symlink to pg_xlog so that it was
> writing to a different volume, and restarted.  This was working fine
> all day so its possibly a red herring but I thought I should mention it.
>
> Any advice is appreciated, thanks!  
>
>
/Hello

U could try  some like "SET/ zero_damaged_pages = on"    and perform a
vacuum-db and may be pg_dump
hope it help!

--------------070306080302000300010207
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <br>
    <div class="moz-cite-prefix">El 04/10/2013 11:40, Mike Broers
      escribi&oacute;:<br>
    </div>
    <blockquote
cite="mid:CAB9893jR-_zaRxeRc0b4rapWLa-M-=Z-vSKt-vxD5uOhFs-z9w@mail.gmail.com"
      type="cite">
      <div dir="ltr">Hello, our postgresql 9.2.4 qa database (thankfully
        its just qa) seems to be hosed. &nbsp;
        <div><br>
        </div>
        <div>Starting at around 3:39am last night I started seeing
          errors about missing files and now I cannot run a pgdump or a
          vacuum without it complaining about files that it cannot find
          with errors like this: ERROR: could not open file
          "base/125542/12631". When I check the filesystem the files are
          indeed not there. &nbsp;The 1am regular vacuum completed and its
          log is clean. &nbsp;The postgres log is clean before these errors
          occurred.
          <div>
            <br>
          </div>
          <div>Since this is qa we do not perform backups, and the
            solution if we cannot repair the problem will be to create a
            fresh qa server but I am intrigued about how to determine
            the source of the problem and the extent of the problem. &nbsp;</div>
          <div><br>
          </div>
          <div>Is there a way to force vacuum to continue on errors or
            an alternate way to help determine all the missing files? &nbsp;</div>
          <div><br>
          </div>
          <div>It might be totally unrelated, but yesterday morning on
            this qa server I stopped postgres, and created a symlink to
            pg_xlog so that it was writing to a different volume, and
            restarted. &nbsp;This was working fine all day so its possibly a
            red herring but I thought I should mention it.</div>
          <div><br>
          </div>
          <div>Any advice is appreciated, thanks! &nbsp;</div>
          <div><br>
          </div>
          <div><br>
          </div>
        </div>
      </div>
    </blockquote>
    <span class="st"><em>Hello <br>
        <br>
        U could try&nbsp; some like "SET</em> zero_damaged_pages = on" &nbsp;&nbsp; and
      perform a vacuum-db and may be pg_dump<br>
      hope it help!<br>
    </span>
  </body>
</html>

--------------070306080302000300010207--