Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA23402; Mon, 16 Nov 92 14:46:14 -0800
Date: Mon, 16 Nov 92 14:46:14 -0800
Message-Id: <9211162246.AA23402@postgres.Berkeley.EDU>
From: bunting@pangaea.dme.nt.gov.au (Chris Bunting 61-89-895442)
Subject: We are having problem with indices
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu
Cc: postgres@postgres.berkeley.edu

I sent this message on Oct 14 and havent recieved any reply, I though I would try again

> From bunting Wed Oct 14 09:27:54 1992
> Date: Wed, 14 Oct 92 09:27:53 CST
> From: bunting (Chris Bunting 95334)
> To: postgres-bug@postgres.berkeley.edu
> Cc: postgres@postgres.berkeley.edu, bunting@pangaea
> Content-Length: 1611
> 
> We are having problem with indices
> 
> When we create an index on a attribute everything is fine, but after a
> period of time the index stops working with one the following results
> 	1) retrieving in the index works depending on the value of the 
> 		attribute.
> 		ie some values are retrieveable
> 		   some are not though a retieve based on a different access 
>                    method works fine ( e.g. "~" ) 
> 
> 	2) The backend core dumps
> 	3) retreives the wrong value.
> 
> This happens on different classes on different databases.
> There are no changes being made to the indexed attribute in some cases.However other attributes are being changed.
> In other cases there are appends replaces and deletes to the attribute.
> 
> The database we are having problems with were fine in the development stage, but when they were put into production, ( ie many users at one time ) , we started having problems.
> 
> We also think that we always get a dead lock immediately befor such a problem.
> 
> On the issue of deadlocks
> 	1) When a deadlock is experienced both transactions always abort
> 		at best.
> 	2) Sometimes the cpu hit 100% indefinitely. But I can not determine
> 	   where in the code ( I think it has something to do with the 
> 	   SpinLocks)
> 	3) The database behave erratically 
> 		ie  indexes dont work, core dumps etc.
> 
> Because of these issues I modified the code so that the elog(WARN) is now an elog(FATAL). This seemed to stablize the databases somewhat but left us with the index problem above.
> 
> I realize that this description is somewhat sketchy, but I am willing to provide more information if required.
> 
> Thanks in advance. 
>