postgres.git / summary / log / commit / refs

commit    8082b759d9b5067dcbdad7090c2e4bf1a4a6842d
Author:   Andres Freund <andres@anarazel.de>
Date:     Mon Nov 24 22:37:09 2025 +0000
First released in: 14.21, 15.16, 16.12, 17.8, 18.2

    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


 src/backend/storage/lmgr/lwlock.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/backend/storage/lmgr/lwlock.c b/src/backend/storage/lmgr/lwlock.c
index 2d43bf2cc13..fc4b42ea5d6 100644
--- a/src/backend/storage/lmgr/lwlock.c
+++ b/src/backend/storage/lmgr/lwlock.c
@@ -1004,7 +1004,7 @@ LWLockWakeup(LWLock *lock)
 			else
 				desired_state &= ~LW_FLAG_RELEASE_OK;
 
-			if (proclist_is_empty(&wakeup))
+			if (proclist_is_empty(&lock->waiters))
 				desired_state &= ~LW_FLAG_HAS_WAITERS;
 
 			desired_state &= ~LW_FLAG_LOCKED;	/* release lock */


[parent: f4e68a32a0cc]