On Mon, 9 Mar 2020 at 14:16, Amit Kapila <amit.kapila16@gmail.com> wrote: > > On Sun, Mar 8, 2020 at 7:58 AM Masahiko Sawada <masahiko.sawada@2ndquadrant.com> wrote: >> > >> > Fair position, as per initial analysis, I think if we do below three >> > things, it should work out without changing to a new way of locking >> > for relation extension or page type locks. >> > a. As per the discussion above, ensure in code we will never try to >> > acquire another heavy-weight lock after acquiring relation extension >> > or page type locks (probably by having Asserts in code or maybe some >> > other way). >> >> The current patch >> (v02_0001-Added-assert-to-verify-that-we-never-try-to-take-any.patch) >> doesn't check that acquiring a heavy-weight lock after page type lock, >> is that right? > > > No, it should do that. > >> >> There is the path doing that: ginInsertCleanup() holds >> a page lock and insert the pending list items, which might hold a >> relation extension lock. > > > Right, I could also see that, but do you see any problem with that? I agree that Assert should cover this case, but I don't see any fundamental problem with that.
I think that could be a problem if we change the group locking so that it doesn't consider page lock type.
I might be missing something, but won't that be a problem only when if there is a case where we acquire page lock after acquiring a relation extension lock? Can you please explain the scenario you have in mind which can create a problem?