Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Josh Berkus
On 8/20/10 8:23 AM, Marko Tiikkaja wrote: > On 2010-08-20 6:19 PM, Kevin Grittner wrote: >> Marko Tiikkaja wrote: >> >>> I think truly serializable transactions still need to SELECT FOR >>> SHARE here for foreign keys to work, no? >> >> That depends on how you look at it. The SSI patch that Dan a

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Kevin Grittner
Greg Stark wrote: > Josh Berkus wrote: >> update session where id = X; >>update order where orderid = 5; >> update order where orderid = 5; > > So i think this will already deadlock. > > A has a exclusive-lock on session and is waiting on order<5>. B > has an exclusive l

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Greg Stark
On Thu, Aug 19, 2010 at 11:51 PM, Josh Berkus wrote: > update session where id = X; >                        update order where orderid = 5; > update order where orderid = 5; So i think this will already deadlock. A has a exclusive-lock on session and is waiting on order<5>. B has an exclusive l

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Marko Tiikkaja
On 2010-08-20 6:19 PM, Kevin Grittner wrote: Marko Tiikkaja wrote: I think truly serializable transactions still need to SELECT FOR SHARE here for foreign keys to work, no? That depends on how you look at it. The SSI patch that Dan and I have been working on doesn't attempt to change the im

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Kevin Grittner
Marko Tiikkaja wrote: > I think truly serializable transactions still need to SELECT FOR > SHARE here for foreign keys to work, no? That depends on how you look at it. The SSI patch that Dan and I have been working on doesn't attempt to change the implementation techniques for foreign keys, b

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Kevin Grittner
I wrote: > I don't see how SSI can be modified to generate some other form of > serialization failure here, but I'm always open to suggestions. Actually, after thinking about it a bit more, the UPDATE statements *do* read the rows before writing, so a naive implementation would see write skew i

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Kevin Grittner
Josh Berkus wrote: >> Two sessions, in transaction: >> >> Process AProcess B >> >> update session where id = X; >> update order where orderid = 5; >> update order where orderid = 5; >> update order where orderid = 5; >> ... deadlock error. > > Johto on IRC pointed

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Marko Tiikkaja
On 2010-08-20 11:39 AM +0300, Josh Berkus wrote: On 8/19/10 3:51 PM, Josh Berkus wrote: Two sessions, in transaction: Process A Process B update session where id = X; update order where orderid = 5; update order where orderid = 5; u

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Thom Brown
On 20 August 2010 09:39, Josh Berkus wrote: > On 8/19/10 3:51 PM, Josh Berkus wrote: >> Kevin, >> >> This one is for you: >> >> Two sessions, in transaction: >> >> Process A             Process B >> >> update session where id = X; >>                       update order where orderid = 5; >> update

Re: [HACKERS] Avoiding deadlocks ...

2010-08-20 Thread Josh Berkus
On 8/19/10 3:51 PM, Josh Berkus wrote: > Kevin, > > This one is for you: > > Two sessions, in transaction: > > Process A Process B > > update session where id = X; > update order where orderid = 5; > update order where orderid = 5; > updat

[HACKERS] Avoiding deadlocks ...

2010-08-19 Thread Josh Berkus
Kevin, This one is for you: Two sessions, in transaction: Process A Process B update session where id = X; update order where orderid = 5; update order where orderid = 5; update order where orderid = 5; ... deadlock error. It seems