On Sat, Mar 7, 2020 at 8:53 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > > Dilip Kumar <dilipbalaut@gmail.com> writes: > > I think instead of the flag we need to keep the counter because we can > > acquire the same relation extension lock multiple times. > > Uh ... what? How would that not be broken usage on its face?
Basically, if we can ensure that while holding the relation extension lock we will not wait for any other lock then we can ignore in the deadlock detection path so that we don't detect the false deadlock due to the group locking mechanism. So if we are already holding the relation extension lock and trying to acquire the same lock-in same mode then it can never wait so this is safe.
> I continue to think that we'd be better off getting all of this > out of the heavyweight lock manager. There is no reason why we > should need deadlock detection, or multiple holds of the same > lock, or pretty much anything that LWLocks don't give you.
Right, we never need deadlock detection for this lock. But, I think there are quite a few cases where we have multiple holds at the same time. e.g, during RelationAddExtraBlocks, while holding the relation extension lock we try to update the block in FSM and FSM might need to add extra FSM block which will again try to acquire the same lock.
But, I think the main reason for not converting it to an LWLocks is because Andres has a concern about inventing new lock mechanism as discuss upthread[1]
Right, that is one point and another is that if we go via the route of converting it to LWLocks, then we also need to think of some solution for page locks that are used in ginInsertCleanup. However, if we go with the approach being pursued [1] then the page locks will be handled in a similar way as relation extension locks.
