pg.ddx.io pgsql-committers@postgresql.org mailing list archivehelp / color / mirror / Atom feed
pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() 6+ messages / 1 participants [nested] [flat]
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/81f773895321ac69d3d71fe9d203e09d072f9c36 Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/8082b759d9b5067dcbdad7090c2e4bf1a4a6842d Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/427e886a79a530aea379e82d2ccbdd6099eac3ad Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/89c8a1b9069f7f1375b114c85258289f77b03a0f Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/da39714965318b2856a0de94a4c817948778969c Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() @ 2025-11-24 23:12 Andres Freund <andres@anarazel.de> 0 siblings, 0 replies; 6+ messages in thread From: Andres Freund @ 2025-11-24 23:12 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/332693e7596909516849e9d7622fbca21b575f28 Modified Files -------------- src/backend/storage/lmgr/lwlock.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2025-11-24 23:12 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de> 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de> 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de> 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de> 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de> 2025-11-24 23:12 pgsql: lwlock: Fix, currently harmless, bug in LWLockWakeup() Andres Freund <andres@anarazel.de>
This inbox is served by DDX for PostgreSQL; see mirroring instructions for how to clone and mirror all data and code used for this inbox