]> 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:55 +0000 (17:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Wed, 27 May 2026 08:19:55 +0000 (17:19 +0900)
commite14b4ea4a6ece9d89a9cb5cf40472664f26f322f
tree45c56551f9393c85a6d16eb822ab9e56561514ad
parentd489c4439e5ba48b6621f34afe75f994f4682cb0
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