On Tue, Nov 18, 2014 at 3:10 PM, Jeff Davis <pg...@j-davis.com> wrote: > On Mon, 2014-11-17 at 14:32 -0500, Robert Haas 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. >
+1 to initially have something like you describe and may be an additional mechanism to grant the non-conflicting locks which are already held by master backend to child backends. I understand that allowing additional non-conflicting locks could lead to some problem if write operations are allowed via child backends as is described as point 1 in Robert's another mail [1]. However I think as initially we want to allow read only operations via child backends, this should be okay and later on if we want to support write via child backends, we might want to consider having an additional property with lock which will allow lock manager or deadlock detector to consider them separately, so that those locks won't be granted to child backends if there is conflict of same with parent. [1]: http://www.postgresql.org/message-id/ca+tgmoygplojo+lg1bebos8gdjwjtq0qdmxsyj4ihfyj11t...@mail.gmail.com With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
