🌐 AI搜索 & 代理 主页
Skip to content

Commit 427e886

Browse files
committed
lwlock: Fix, currently harmless, bug in LWLockWakeup()
Accidentally the code in LWLockWakeup() checked the list of to-be-woken up processes to see if LW_FLAG_HAS_WAITERS should be unset. That means that HAS_WAITERS would not get unset immediately, but only during the next, unnecessary, call to LWLockWakeup(). Luckily, as the code stands, this is just a small efficiency issue. However, if there were (as in a patch of mine) a case in which LWLockWakeup() would not find any backend to wake, despite the wait list not being empty, we'd wrongly unset LW_FLAG_HAS_WAITERS, leading to potentially hanging. While the consequences in the backbranches are limited, the code as-is confusing, and it is possible that there are workloads where the additional wait list lock acquisitions hurt, therefore backpatch. Discussion: https://postgr.es/m/fvfmkr5kk4nyex56ejgxj3uzi63isfxovp2biecb4bspbjrze7@az2pljabhnff Backpatch-through: 14
1 parent 232e0f5 commit 427e886

File tree

1 file changed

+1
-1
lines changed

1 file changed

+1
-1
lines changed

src/backend/storage/lmgr/lwlock.c

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -994,7 +994,7 @@ LWLockWakeup(LWLock *lock)
994994
else
995995
desired_state &= ~LW_FLAG_RELEASE_OK;
996996

997-
if (proclist_is_empty(&wakeup))
997+
if (proclist_is_empty(&lock->waiters))
998998
desired_state &= ~LW_FLAG_HAS_WAITERS;
999999

10001000
desired_state &= ~LW_FLAG_LOCKED; /* release lock */

0 commit comments

Comments
 (0)