Skip site navigation (1) Skip section navigation (2)

Re: database troubles - various errors

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 (view raw, whole thread or download thread mbox)
Lists: pgsql-general
Memory has been tested, and it was okay.  What's the best way to test the
CPU and hard drive / controller?
----- 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
> > dual cpu system, running on Gentoo Linux, with kernel 2.6.7.  Data is
> > on a JFS partition.  Before we installed the server, memory was fully
> > and no problems were found.  Postgres is version 7.4.3.
> >
> >     We've had a number of different errors.  One of the most popular
> > to be a Cannot open segment.  This usually occurs on an index, generally
> > 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
> > database was reindexed at some point last week.  The table with the
> > 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
> > 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
> > 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
> >
> > Basically, I'd like to know if anyone has seen any problems similar to
> > 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.

In response to


pgsql-general by date

Next:From: Manfred KoizarDate: 2004-08-23 17:57:01
Subject: Re: Table access method not behaving like Oracle (index vs sequential scan). Examples and stats provided.
Previous:From: Manfred KoizarDate: 2004-08-23 16:59:04
Subject: Re: Column as result of subtraction of two other columns?

Privacy Policy | About PostgreSQL
Copyright © 1996-2018 The PostgreSQL Global Development Group