Re: Deadlock with tsearch2 index ...

On Tue, 31 May 2005, Tom Lane wrote:

> (2) we acquire and release the index lock for each *tuple* rather than 
> each statement.  Then client2 doesn't hold the index lock while it's 
> waiting for the row lock to clear.
>
> Neither of these cures sounds attractive :-(.  I think #1 would probably 
> do as much to create deadlock cases as to prevent them.  #2 would avoid 
> the deadlock but the performance cost would be high.

But ... this wouldn't affect SELECT operations, would it?  And only GiST 
related operations?  Would the performance loss be noticeable?  And, would 
the performance cost not be worth getting rid of the deadlocks, until the 
concurrency issues can be properly dealt with?

----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664