------=_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-im****ting 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@[EMAIL PROTECTED]
>
wrote:
> On Tue, Apr 29, 2008 at 11:18 AM, e t <albunix@[EMAIL PROTECTED]
> 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 ****ting 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,<br><br>thanks for your kind reply.<br><br>We are indeed running rhel
2 es, as our application requires such.<br><br>I was able to correct this,
including permission error, by <br><br>1)getting a right after the crash
dump of the DB<br>
2)dropping the DB<br>3)re-installing the RPM's via force
option<br>4)re-im****ting the DB<br><br>I am not aware of how one
re-indexes the table(s)<br><br>Is there any options or what's the
syntax to do so, <br>in case we ever will need such in the future.<br>
<br>Thank you.<br><br><div class="gmail_quote">On Tue, Apr 29, 2008 at
2:52 PM, Scott Marlowe <<a
href="mailto:scott.marlowe@[EMAIL PROTECTED]
">scott.marlowe@[EMAIL PROTECTED]
>>
wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid
rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">On Tue, Apr 29, 2008 at 11:18 AM, e t <<a
href="mailto:albunix@[EMAIL PROTECTED]
">albunix@[EMAIL PROTECTED]
>> wrote:<br>
> Hello,<br>
><br>
> we run<br>
><br>
> 7.4.7<br>
><br>
> on a Redhat RHEL server.<br>
<br>
</div>Two points.<br>
1: The 7.4.x series is pretty old. You should consider upgrading to
a<br>
newer version when you have time. 8.3.1 is stable but a little
new.<br>
8.2.7 is very stable and much faster than 7.4.<br>
2: 7.4 series is up to <a href="http://7.4.19."
target="_blank">7.4.19.</a> You may be missing 3 years of
updates,<br>
unless you are using RedHat's version and they are back ****ting
fixes<br>
to <a href="http://7.4.7."
target="_blank">7.4.7.</a> I didn't
think they did that, but Tom Lane would be a good<br>
person to ask about that.<br>
<div class="Ih2E3d"><br>
> Today that was a severe server crash and NOC seems to have
repeatedly<br>
> attempted a reboot without properly unmounting the file
systems.<br>
<br>
</div>The machine that gives them a banana when they push a button
probably<br>
wasn't working quite right :)<br>
<div class="Ih2E3d"><br>
> I am getting errors such as the following<br>
><br>
> Apr 29 13:15:34 cp postgres[4961]: [106-1] ERROR: could not
open relation<br>
> "users_pkey": Permission denied<br>
> Apr 29 13:15:34 cp postgres[4961]: [107-1] ERROR: could not
open relation<br>
> "users_pkey": Permission denied<br>
> Apr 29 13:15:34 cp postgres[4957]: [113-1] ERROR: could
not open relation<br>
> "users_pkey": Permission denied<br>
><br>
> when attempting to have my application connect to the DB<br>
><br>
> Please let me know what sort of procedure are available to us<br>
> to have such functionality restored.<br>
<br>
</div>you should restore from backup if possible.<br>
<br>
> We do have backups.<br>
<br>
pg_dump backups (good thing) or file system backups (maybe good,<br>
likely not coherent)<br>
<div class="Ih2E3d"><br>
> Being it is one day old, are we going to loose information when
attempting<br>
> to do a restore?<br>
<br>
</div>Well, if you can't connect, then no. OTOH, if you can
still connect<br>
and you've been updating data, then yes. you'll lost
everything you<br>
had since your last backup.<br>
<br>
You may be able to fix things. Trying reindexing the failing table /
indexes.<br>
</blockquote></div><br>
------=_Part_7567_20569217.1209557736170--
|
