Re: group locking: incomplete patch, just for discussion

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: group locking: incomplete patch, just for discussion
Дата
Msg-id CA+TgmoaH8We+SXHPXa0d2J5qGMTYTyjFV2-kaV=w-rqWRqDtAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: group locking: incomplete patch, just for discussion  (Amit Kapila <amit.kapila16@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Petr Jelinek
Дата:
Сообщение: Re: Column/type dependency recording inconsistencies
Следующее
От: Robert Haas
Дата:
Сообщение: Re: psql tab completion: \c [ dbname [ username ] ]