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 по дате отправления: