Re: group locking: incomplete patch, just for discussion

On Wed, Nov 19, 2014 at 9:33 PM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Tue, Nov 18, 2014 at 4:40 AM, Jeff Davis <pgsql(at)j-davis(dot)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