public inbox for [email protected]help / color / mirror / Atom feed
pgsql: Fix procLatch ownership race in ProcKill() 6+ messages / 1 participants [nested] [flat]
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/12c9b8b422e27bc1fc1475379b29c177cc988589 Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e14b4ea4a6ece9d89a9cb5cf40472664f26f322f Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/4e8edf53f91aff5cb00600b3f5bf33d22aed4f12 Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_15_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/e786fb5aa7f29abaae6e912a5a417843f44c0899 Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ REL_14_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/db4d12fc97ab2f4542092782fbcc934d584d0850 Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
* pgsql: Fix procLatch ownership race in ProcKill() @ 2026-05-27 08:20 Michael Paquier <[email protected]> 0 siblings, 0 replies; 6+ messages in thread From: Michael Paquier @ 2026-05-27 08:20 UTC (permalink / raw) To: [email protected] Fix procLatch ownership race in ProcKill() DisownLatch() was executed after the PGPROC entry of the process terminated is pushed back into a freelist. A newly-forked backend that recycles the slot could call OwnLatch() and PANIC with a "latch already owned by PID", taking down the server. There were two scenarios related to lock groups where this issue could be reached: * A follower pushes the leader's PGPROC back to the freelist while the leader has not yet called DisownLatch() in its own ProcKill(). * A leader outliving all its followers pushes its own PGPROC onto the freelist before reaching DisownLatch(), which would be the most common scenario. This issue is fixed by calling SwitchBackToLocalLatch() and DisownLatch() at an earlier phase of ProcKill(), before any freelist manipulation happens, so that the slot of the backend terminated is never exposed as owning a latch. Note that pgstat_reset_wait_event_storage() is kept at a later stage. An upcoming commit will take advantage of that by introducing a test able to check the original PANIC scenario. Author: Vlad Lesin <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Michael Paquier <[email protected]> Discussion: https://postgr.es/m/[email protected] Backpatch-through: 14 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/84b9d6bceab6e6ec4ff49fa52a7fc90d85e3798c Modified Files -------------- src/backend/storage/lmgr/proc.c | 30 +++++++++++++++++++----------- 1 file changed, 19 insertions(+), 11 deletions(-) ^ permalink raw reply [nested|flat] 6+ messages in thread
end of thread, other threads:[~2026-05-27 08:20 UTC | newest] Thread overview: 6+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[email protected]> 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[email protected]> 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[email protected]> 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[email protected]> 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[email protected]> 2026-05-27 08:20 pgsql: Fix procLatch ownership race in ProcKill() Michael Paquier <[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