Received: from localhost (unknown [200.46.204.184]) by developer.postgresql.org (Postfix) with ESMTP id 07ECB2E0064 for ; Wed, 30 Apr 2008 11:08:51 -0300 (ADT) Received: from developer.postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 77641-01-5 for ; Wed, 30 Apr 2008 11:08:37 -0300 (ADT) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.5 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by developer.postgresql.org (Postfix) with ESMTP id D2EA22E0049 for ; Wed, 30 Apr 2008 11:08:35 -0300 (ADT) Received: by wa-out-1112.google.com with SMTP id n4so283420wag.5 for ; Wed, 30 Apr 2008 07:08:34 -0700 (PDT) Received: by 10.114.94.1 with SMTP id r1mr595382wab.31.1209557736176; Wed, 30 Apr 2008 05:15:36 -0700 (PDT) Received: by 10.114.191.5 with HTTP; Wed, 30 Apr 2008 05:15:36 -0700 (PDT) Message-ID: <82d6a2d00804300515w7529cc67pb754d39ca6856f13@mail.gmail.com> Date: Wed, 30 Apr 2008 08:15:36 -0400 From: "e t" To: "Scott Marlowe" Subject: Re: server crash, need to restore DB functionality Cc: pgsql-admin@postgresql.org In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_7567_20569217.1209557736170" References: <82d6a2d00804291018h3f05bbe3gb21cae15eb7a0643@mail.gmail.com> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.001 tagged_above=0 required=5 tests=HTML_MESSAGE=0.001 X-Spam-Level: X-Archive-Number: 200804/305 X-Sequence-Number: 29069 ------=_Part_7567_20569217.1209557736170 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All, thanks for your kind reply. We are indeed running rhel 2 es, as our application requires such. I was able to correct this, including permission error, by 1)getting a right after the crash dump of the DB 2)dropping the DB 3)re-installing the RPM's via force option 4)re-importing the DB I am not aware of how one re-indexes the table(s) Is there any options or what's the syntax to do so, in case we ever will need such in the future. Thank you. On Tue, Apr 29, 2008 at 2:52 PM, Scott Marlowe wrote: > On Tue, Apr 29, 2008 at 11:18 AM, e t wrote: > > Hello, > > > > we run > > > > 7.4.7 > > > > on a Redhat RHEL server. > > Two points. > 1: The 7.4.x series is pretty old. You should consider upgrading to a > newer version when you have time. 8.3.1 is stable but a little new. > 8.2.7 is very stable and much faster than 7.4. > 2: 7.4 series is up to 7.4.19. You may be missing 3 years of updates, > unless you are using RedHat's version and they are back porting fixes > to 7.4.7. I didn't think they did that, but Tom Lane would be a good > person to ask about that. > > > Today that was a severe server crash and NOC seems to have repeatedly > > attempted a reboot without properly unmounting the file systems. > > The machine that gives them a banana when they push a button probably > wasn't working quite right :) > > > I am getting errors such as the following > > > > Apr 29 13:15:34 cp postgres[4961]: [106-1] ERROR: could not open > relation > > "users_pkey": Permission denied > > Apr 29 13:15:34 cp postgres[4961]: [107-1] ERROR: could not open > relation > > "users_pkey": Permission denied > > Apr 29 13:15:34 cp postgres[4957]: [113-1] ERROR: could not open > relation > > "users_pkey": Permission denied > > > > when attempting to have my application connect to the DB > > > > Please let me know what sort of procedure are available to us > > to have such functionality restored. > > you should restore from backup if possible. > > > We do have backups. > > pg_dump backups (good thing) or file system backups (maybe good, > likely not coherent) > > > Being it is one day old, are we going to loose information when > attempting > > to do a restore? > > Well, if you can't connect, then no. OTOH, if you can still connect > and you've been updating data, then yes. you'll lost everything you > had since your last backup. > > You may be able to fix things. Trying reindexing the failing table / > indexes. > ------=_Part_7567_20569217.1209557736170 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline All,

thanks for your kind reply.

We are indeed running rhel 2 es, as our application requires such.

I was able to correct this, including permission error, by

1)getting a right after the crash dump of the DB
2)dropping the DB
3)re-installing the RPM's via force option
4)re-importing the DB

I am not aware of how one re-indexes the table(s)

Is there any options or what's the syntax to do so,
in case we ever will need such in the future.

Thank you.

On Tue, Apr 29, 2008 at 2:52 PM, Scott Marlowe <scott.marlowe@gmail.com> wrote:
On Tue, Apr 29, 2008 at 11:18 AM, e t <albunix@gmail.com> wrote:
> Hello,
>
> we run
>
> 7.4.7
>
> on a Redhat RHEL server.

Two points.
1: The 7.4.x series is pretty old.  You should consider upgrading to a
newer version when you have time.  8.3.1 is stable but a little new.
8.2.7 is very stable and much faster than 7.4.
2: 7.4 series is up to 7.4.19.  You may be missing 3 years of updates,
unless you are using RedHat's version and they are back porting fixes
to 7.4.7.  I didn't think they did that, but Tom Lane would be a good
person to ask about that.

> Today that was a severe server crash and NOC seems to have repeatedly
> attempted a reboot without properly unmounting  the file systems.

The machine that gives them a banana when they push a button probably
wasn't working quite right :)

>  I am getting errors such as the following
>
> Apr 29 13:15:34 cp postgres[4961]: [106-1] ERROR:  could not open relation
> "users_pkey": Permission denied
> Apr 29 13:15:34 cp postgres[4961]: [107-1] ERROR:  could not open relation
> "users_pkey": Permission denied
>  Apr 29 13:15:34 cp postgres[4957]: [113-1] ERROR:  could not open relation
> "users_pkey": Permission denied
>
> when attempting to have my application connect to the DB
>
> Please let me know what sort of procedure are available to us
>  to have such functionality restored.

you should restore from backup if possible.

> We do have backups.

pg_dump backups (good thing) or file system backups (maybe good,
likely not coherent)

> Being it is one day old, are we going to loose information when attempting
> to do a restore?

Well, if you can't connect, then no.  OTOH, if you can still connect
and you've been updating data, then yes.  you'll lost everything you
had since your last backup.

You may be able to fix things.  Trying reindexing the failing table / indexes.

------=_Part_7567_20569217.1209557736170--