On Fri, Mar 13, 2020 at 3:39 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > On Fri, Mar 13, 2020 at 8:37 AM Dilip Kumar <dilipbal...@gmail.com> wrote: > > > > On Thu, Mar 12, 2020 at 5:28 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > > > > > > On Thu, Mar 12, 2020 at 11:15 AM Dilip Kumar <dilipbal...@gmail.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
