Re: group locking: incomplete patch, just for discussion

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: group locking: incomplete patch, just for discussion
Дата
Msg-id 824FF69B-501A-4D5F-B74B-42D4AE6777F4@2ndquadrant.com
обсуждение исходный текст
Ответ на Re: group locking: incomplete patch, just for discussion  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On November 13, 2014 8:50:18 PM CET, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>Robert Haas <robertmhaas@gmail.com> writes:
>> On Thu, Nov 13, 2014 at 3:38 AM, Jeff Davis <pgsql@j-davis.com>
>wrote:
>>> If two backends both have an exclusive lock on the relation for a
>join
>>> operation, that implies that they need to do their own
>synchronization,
>>> because obviously the lock manager is not doing it for them.
>
>> This doesn't make sense to me.  Why would they need to synchronize
>> access to a relation in order to join it?
>
>What's more to the point: why would you take an exclusive lock just to
>do a join?

Robert's case basically rest on the premise that it's useful & correct when normally conflicting locks don't conflict
whennormal processes and its workers acquire them. I have serious doubts about the safety of that and the complexity it
requires.

Obviously a join won't need an exclusive lock itself - but with Robert's design a join inside a transaction that locked
arelation could still be parallelized, even if that rel is involved.
 

Andred

-- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

Andres Freund                       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: alter user/role CURRENT_USER
Следующее
От: Robert Haas
Дата:
Сообщение: alternative model for handling locking in parallel groups