From: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, Andres Freund <andres(at)2ndquadrant(dot)com>, Simon Riggs <simon(at)2ndquadrant(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: group locking: incomplete patch, just for discussion |
Date: | 2014-11-20 04:45:18 |
Message-ID: | CAA4eK1K5_V_41wwFrxTQFb98orifsKc6n7p+JWT7+jKA0VeHow@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2014-11-20 05:06:38 | Re: alternative model for handling locking in parallel groups |
Previous Message | Abhijit Menon-Sen | 2014-11-20 04:22:01 | Re: What exactly is our CRC algorithm? |