Thread: Lock conflict
Hello all,
This PostgreSQL version is 11.9.
In LockAcquireExtended(), why if lock requested conflicts with locks requested by waiters, must join
wait queue. Why does the lock still check for conflict with the lock requested,
rather than check for directly with conflict with the already-held lock?
I think lock requested only check for conflict with already-held lock, if there is no conflict, the lock should be granted.
Best regards
On Mon, 20 Mar 2023 at 14:58, 席冲(宜穆) <xichong.xc@alibaba-inc.com> wrote: > I think lock requested only check for conflict with already-held lock, if there is no conflict, the lock should be granted. That would mean that stronger locks such as AEL might never be granted if there was never any moment when no other conflicting locks existed (which is very likely to happen on busy OLTP-type workloads). The way it works now makes it fair so that weaker locks don't jump the queue. David