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: [EMAIL PROTECTED] Yahoo!: yscrappy ICQ: 7615664
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
