Return-Path: pg_adm@postgres.berkeley.edu
Received: by postgres.Berkeley.EDU (5.61/1.29)
	id AA14209; Wed, 3 Feb 93 18:11:23 -0800
Date: Wed, 3 Feb 93 18:11:23 -0800
Message-Id: <9302040211.AA14209@postgres.Berkeley.EDU>
From: bunting@pangaea.dme.nt.gov.au (Chris Bunting 61-89-895442)
Subject: Index problems
To: postgres@postgres.berkeley.edu
Sender: pg_adm@postgres.berkeley.edu


I sent the following bug report some time ago. I never got a reply so I thought that I would try again ( No harm in trying ). 
> 
> 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. 
> 


m