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. -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
0002-Allow-relation-extension-and-page-locks-to-conflict-.v2.patch
Description: Binary data
