From: | "A Palmblad" <adampalmblad(at)yahoo(dot)ca> |
---|---|
To: | "Scott Marlowe" <smarlowe(at)qwest(dot)net> |
Cc: | "General Postgres" <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: database troubles - various errors |
Date: | 2004-08-23 17:51:21 |
Message-ID: | 006801c48939$cd18c3f0$97019696@AERS04 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Memory has been tested, and it was okay. What's the best way to test the
CPU and hard drive / controller?
-Adam
----- Original Message -----
From: "Scott Marlowe" <smarlowe(at)qwest(dot)net>
To: "A Palmblad" <adampalmblad(at)yahoo(dot)ca>
Cc: "General Postgres" <pgsql-general(at)postgresql(dot)org>
Sent: Monday, August 23, 2004 9:41 AM
Subject: Re: [GENERAL] database troubles - various errors
> On Mon, 2004-08-23 at 10:14, A Palmblad wrote:
> > We're having a lot of trouble with one of our new servers. It's an
AMD64
> > dual cpu system, running on Gentoo Linux, with kernel 2.6.7. Data is
stored
> > on a JFS partition. Before we installed the server, memory was fully
tested
> > and no problems were found. Postgres is version 7.4.3.
> >
> > We've had a number of different errors. One of the most popular
seems
> > to be a Cannot open segment. This usually occurs on an index, generally
the
> > primary key index. A reindex will fix the problem.
> >
> > Last night we got this one: ERROR: could not find a feasible split
> > point for "some_index". This one seemed funny because it was on a btree
> > index of one column. A reindex made the error go away. Every table in
the
> > database was reindexed at some point last week. The table with the
index
> > involved uses all standard data types and has no non-btree indexes.
> >
> > Another one we've had and fixed was ERROR: duplicate key violates unique
> > constraint "pg_class_oid_index".
> >
> > One of the most annoying errors is occassional index corruption that is
not
> > reported. We make use of gist tsearch2 indexes, and sometimes they will
> > decide to stop working without an error. The only clue we have that
there
> > is a problem is that search words that generally return big results will
> > return any results or very few. A reindex will fix the problem.
> >
> > Vacuums are done manually, but generally there's at least one every
week.
> >
> > Basically, I'd like to know if anyone has seen any problems similar to
this,
> > and if they have any suggestions on how to fix these issues.
>
> Have you tested the memory, hard drive and CPU on this machine to ensure
> proper operation? This sounds like a hardware problem to me.
>
>
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2004-08-23 17:57:01 | Re: Table access method not behaving like Oracle (index vs sequential scan). Examples and stats provided. |
Previous Message | Manfred Koizar | 2004-08-23 16:59:04 | Re: Column as result of subtraction of two other columns? |