]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix procLatch ownership race in ProcKill()
authorMichael Paquier <michael@paquier.xyz>
Wed, 27 May 2026 08:19:20 +0000 (17:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Wed, 27 May 2026 08:19:20 +0000 (17:19 +0900)
commit84b9d6bceab6e6ec4ff49fa52a7fc90d85e3798c
tree9af70bb0d8a843eb1605d972de1fe0bcd289595d
parent56310452318cee4bb8c291be126ce0c2b2affa5f
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 <vladlesin@gmail.com>
Reviewed-by: Andrey Borodin <x4mmm@yandex-team.ru>
Reviewed-by: Michael Paquier <michael@paquier.xyz>
Discussion: https://postgr.es/m/d2983796-2603-41b7-a66e-fc8489ddb954@gmail.com
Backpatch-through: 14
src/backend/storage/lmgr/proc.c