On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila amit.kapil...@gmail.com
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
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila amit.kapil...@gmail.com 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
On Wed, Nov 19, 2014 at 8:56 PM, Robert Haas robertmh...@gmail.com wrote:
On Tue, Nov 18, 2014 at 8:53 AM, Amit Kapila amit.kapil...@gmail.com
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
On Fri, Nov 14, 2014 at 2:29 AM, Robert Haas robertmh...@gmail.com 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
On Fri, Nov 14, 2014 at 12:03 PM, Andres Freund and...@2ndquadrant.com 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
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 mutually
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
