Re: [HACKERS] Moving relation extension locks out of heavyweight lock manager

On Fri, Mar 13, 2020 at 3:39 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
>
> On Fri, Mar 13, 2020 at 8:37 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> >
> > On Thu, Mar 12, 2020 at 5:28 PM Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> > >
> > > On Thu, Mar 12, 2020 at 11:15 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > > >
> > > > I have fixed this in the attached patch set.
> > > >
> > >
> > > I have modified your
> > > v4-0003-Conflict-Extension-Page-lock-in-group-member patch. The
> > > modifications are (a) Change src/backend/storage/lmgr/README to
> > > reflect new behaviour, (b) Introduce a new macro LOCK_LOCKTAG which
> > > slightly simplifies the code, (c) moved the deadlock.c check a few
> > > lines up and (d) changed a few comments.
> >
> > Changes look fine to me.
> >
>
> Today, while looking at this patch again, I realized that there is a
> where we sometimes allow group members to jump the wait queue. This
> is primarily to avoid creating deadlocks (see ProcSleep). Now,
> ideally, we don't need this for relation extension or page locks as
> those can never lead to deadlocks. However, the current code will
> give group members more priority to acquire relation extension or page
> locks if any one of the members has held those locks. Now, if we want
> we can prevent giving group members priority for these locks, but I am
> not sure how important is that case. So, I have left that as it is by
> adding a few comments. What do you think?
>
> Additionally, I have changed/added a few more sentences in README.

I have included all your changes in the latest patch set.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com