On Wed, 13 Nov 2002, Peter Schindler wrote: > But, if a lot of inserts happens into the child table and there is a > mix of short and long running transactions, the likelihood of blocking > is very high, even the inserts are independent and everything is ok > (prim. key etc.). This is even more extreme, the smaller parent table > is. > > FYI, I've tried the same with Oracle and there is no such problem. The > insert in the second session will come back immediately without > blocking, though it will still maintain the integrity from other txns. > > I wonder if there is a lower level way to maintain the locking and > having the same behavior as oracle. So, instead of using a "SELECT ... > FOR UPDATE", using some pg function to lock a row with a different > mode?
I've been working on something of the sort. I've got a test patch (against about 7.3b2) that I'm trying to validate which cases it does and does not work for. I'm still looking for more volunteers if you've got a dev system you're willing to use. :) Right now, I know that it has a hole that lets through invalid data in one case that it got while trying to fix a deadlock case. Hopefully in the next week or so I'll have figured out a way around it. ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
