Re: group locking: incomplete patch, just for discussion - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: group locking: incomplete patch, just for discussion
Date
Msg-id 1416503532.2998.231.camel@jeff-desktop
Whole thread Raw
In response to Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: group locking: incomplete patch, just for discussion  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, 2014-11-20 at 11:22 -0500, Robert Haas wrote:
> 2. Propagate pre-existing locks from the user backend to all the workers.
> 
> I initially proposed #1, but now I think #2 solves more of the
> problems for less code.

OK. The primary concern with that is unintended consequences. But it's
reasonable for you to ask for something more concrete. I will think on
this more.

A few things I'm thinking about now:
* What do you mean by "pre-existing"? Locks existing prior to what
event? (I don't think that's exactly what you meant.)* What's the conceptual difference between granting locks that
would
otherwise conflict with another process in the group (which is what this
proposal is about) and having exactly the same set of locks? Is there
any?* Let's say you have processes A1 and A2 in one group, and B. A1 and B
both have an AccessShare lock, and A2 tries to acquire an exclusive
lock. B is waiting on A2. That's still a deadlock, right?

Regards,Jeff Davis






pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: WAL format and API changes (9.5)
Next
From: Andres Freund
Date:
Subject: Re: group locking: incomplete patch, just for discussion