On Tue, Nov 18, 2014 at 3:10 PM, Jeff Davis <
pgsql@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.