public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). 5+ messages / 1 participants [nested] [flat]
* pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). @ 2026-05-27 23:26 Masahiko Sawada <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Masahiko Sawada @ 2026-05-27 23:26 UTC (permalink / raw) To: [email protected] Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/d79bf7612a07a6f053f4122a8bf88754217cd1c9 Modified Files -------------- src/backend/storage/ipc/procsignal.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). @ 2026-05-27 23:26 Masahiko Sawada <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Masahiko Sawada @ 2026-05-27 23:26 UTC (permalink / raw) To: [email protected] Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1a9b1cc18e068e181f85ab8712ac4d2274d609ab Modified Files -------------- src/backend/storage/ipc/procsignal.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). @ 2026-05-27 23:26 Masahiko Sawada <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Masahiko Sawada @ 2026-05-27 23:26 UTC (permalink / raw) To: [email protected] Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/a651b8a89e7f76696ddc89a565b39039568840bc Modified Files -------------- src/backend/storage/ipc/procsignal.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). @ 2026-05-27 23:26 Masahiko Sawada <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Masahiko Sawada @ 2026-05-27 23:26 UTC (permalink / raw) To: [email protected] Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/cdb9b2830d48391ffa30fa64f5eed28cc63a63ca Modified Files -------------- src/backend/storage/ipc/procsignal.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
* pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). @ 2026-05-27 23:26 Masahiko Sawada <[email protected]> 0 siblings, 0 replies; 5+ messages in thread From: Masahiko Sawada @ 2026-05-27 23:26 UTC (permalink / raw) To: [email protected] Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Previously, ProcSignalInit() read the global barrier generation before publishing its PID into pss_pid. This created a race condition: a process could initialize its local generation with an older global value, while a concurrent EmitProcSignalBarrier() might skip that process because its pss_pid was still zero. This resulted in WaitForProcSignalBarrier() hanging indefinitely. Fix this by publishing pss_pid before reading psh_barrierGeneration with a memory barrier so that the store to pss_pid is ordered before the load. A concurrent EmitProcSignalBarrier() then either observes the published PID and signals this slot, or completes its generation increment before we load it. While this race has become more visible due to recent features using signal barriers in more places (such as online wal_level changes), the issue is theoretically present since signal barriers were introduced to release smgr caches (e.g., in DROP DATABASE). v14 has the procsiangl barrier infrastricutre but no in-tree caller that actually emits a barrier, so the case is unreachable there. This issue was also reported by buildfarm member flaviventris. Reported-by: Melanie Plageman <[email protected]> Reviewed-by: Alexander Lakhin <[email protected]> Reviewed-by: Matthias van de Meent <[email protected]> Discussion: https://postgr.es/m/CAEze2WgAJmWReDN7Chtba8Er2YBvKCoa0KVN25-1evnTrHsLyA@mail.gmail.com Backpatch-through: 15 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/159324a73a39f644c8bdd778a22b491de7a472e4 Modified Files -------------- src/backend/storage/ipc/procsignal.c | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) ^ permalink raw reply [nested|flat] 5+ messages in thread
end of thread, other threads:[~2026-05-27 23:26 UTC | newest] Thread overview: 5+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-27 23:26 pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Masahiko Sawada <[email protected]> 2026-05-27 23:26 pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Masahiko Sawada <[email protected]> 2026-05-27 23:26 pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Masahiko Sawada <[email protected]> 2026-05-27 23:26 pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Masahiko Sawada <[email protected]> 2026-05-27 23:26 pgsql: Fix race between ProcSignalInit() and EmitProcSignalBarrier(). Masahiko Sawada <[email protected]>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox