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

From Robert Haas
Subject Re: group locking: incomplete patch, just for discussion
Date
Msg-id CA+TgmoaH8We+SXHPXa0d2J5qGMTYTyjFV2-kaV=w-rqWRqDtAA@mail.gmail.com
Whole thread Raw
In response to Re: group locking: incomplete patch, just for discussion  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
On Mon, Nov 10, 2014 at 6:33 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> I think this logic can sometimes block processes from acquiring a lock
> which no one is holding.  Assume Group-1 (G-1) is waiting on two locks
> (Lock L1 on Table T1 and Lock L2 on Table T2) which are held by
> unrelated processes P-2 and P-3 respectively; now P-3 releases the
> lock on table T-2 and cannot grant it to G-1 who is waiting on this lock
> because still L-1 lock cannot be granted to G-1.

That's not what I meant.  I meant we shouldn't grant a lock *on a
particular object* to any process on the group until all lock requests
*for that object* can be granted.  Waiting until every awaited lock in
the system can be granted in all requested modes would be really hard
to implement and probably have all kinds of problems (as you point out
here).

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Petr Jelinek
Date:
Subject: Re: Column/type dependency recording inconsistencies
Next
From: Robert Haas
Date:
Subject: Re: psql tab completion: \c [ dbname [ username ] ]