]> 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:58 +0000 (17:19 +0900)
committerMichael Paquier <michael@paquier.xyz>
Wed, 27 May 2026 08:19:58 +0000 (17:19 +0900)
commite786fb5aa7f29abaae6e912a5a417843f44c0899
tree36bc7210b11873665ec9b49d3e174bb92c444ce3
parentd5cc6df608018f4dbf32542fe6bec405d2d770c0
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