Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-20 Thread Amit Kapila
On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas wrote: > > On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila wrote: > >> After thinking about these cases for a bit, I came up with a new > >> possible approach to this problem. Suppose that, at the beginning of > >> parallelism, when we decide to start up

Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-19 Thread Amit Kapila
On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas wrote: > > On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila wrote: > > Won't this be addressed because both updates issued from myfunc() > > are considered as separate commands, so w.r.t lock it should behave > > as 2 different updates in same transaction.

Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-19 Thread Robert Haas
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila wrote: > Won't this be addressed because both updates issued from myfunc() > are considered as separate commands, so w.r.t lock it should behave > as 2 different updates in same transaction. I think there may be more > things to make updates possible v

Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-18 Thread Amit Kapila
On Fri, Nov 14, 2014 at 2:29 AM, Robert Haas wrote: > > Discussion of my incomplete group locking patch seems to have > converged around two points: (1) Everybody agrees that undetected > deadlocks are unacceptable. (2) Nobody agrees with my proposal to > treat locks held by group members as mutu

Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-16 Thread Robert Haas
On Fri, Nov 14, 2014 at 12:03 PM, Andres Freund wrote: > Note that you'd definitely not want to do this naively - currently > there's baked in assumptions into the vaccum code that only one backend > is doing parts of it. > > I think there's Did something you intended get left out here? >> 4. Pa

Re: [HACKERS] alternative model for handling locking in parallel groups

2014-11-14 Thread Andres Freund
Hi, On 2014-11-13 15:59:11 -0500, Robert Haas wrote: > Discussion of my incomplete group locking patch seems to have > converged around two points: (1) Everybody agrees that undetected > deadlocks are unacceptable. (2) Nobody agrees with my proposal to > treat locks held by group members as mutua

[HACKERS] alternative model for handling locking in parallel groups

2014-11-13 Thread Robert Haas
Discussion of my incomplete group locking patch seems to have converged around two points: (1) Everybody agrees that undetected deadlocks are unacceptable. (2) Nobody agrees with my proposal to treat locks held by group members as mutually non-conflicting. As was probably evident from the emails