On Wed, Nov 19, 2014 at 9:33 PM, Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Nov 18, 2014 at 4:40 AM, Jeff Davis <pg...@j-davis.com> wrote: > >> To reiterate the basic problem here, if we do nothing at all about the > >> lock manager, a parallel backend can stall trying to grab an > >> AccessExclusiveLock that the user backend alread holds, either because > >> the user backend holds an AccessExclusiveLock as well, or because some > >> other process is waiting for one, we'll deadlock and not notice. > > > > My feeling is that we should keep the concept of a group and group > > leader from your patch, and improve the deadlock detector to make use of > > that information (looking at the code, it looks doable but not trivial). > > But unless I am missing something, we should separate out the lock > > sharing, and defer that until later. > > Doing as you propose solves this problem: > > 1. Backend A-1 acquires AccessShareLock on relation R. > 2. Backend B waits for AccessExclusiveLock on relation R. > 3. Backend A-2 waits for AccessShareLock on relation R. > > Knowing that A-1 and A-2 are related, the deadlock detector can move > A-2 ahead of B and grant the lock. All is well. > > But your proposal does not solve this problem: > > 1. Backend A-1 acquires AccessExclusiveLock on relation R. > 2. Backend A-2 waits for AccessShareLock on relation R. >
I think that could be doable under above proposal by making lock conflicts (LockCheckConflicts) code aware of parallel group. But it might lead to a problem incase it allows to acquire a lock to parallel worker where it should not like in cases of Relation extension as mentioned by you on another thread. However I think we should block any such operations and allow read only operations in parallel workers. It seems to me that we have to do lot more things to build a capability to allow parallel workers to perform write operations. > > Even if you could somehow solve that problem, there's also the issue > of plan caching. If we make a parallel plan for an SQL statement > inside a PL/pgsql procedure because our backend holds no strong locks, > and then we acquire a strong lock on a relevant relation, we have to > invalidate that plan. I think that will add complexity inside the > plan cache machinery. It seems to me that it would be better to > handle these issues inside the lock manager rather than letting them > creep into other parts of the system. > How would changes in lock manager guarantee that it won't be problem in anycase? With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
