[PATCH] Prevent repeated deadlock-check signals in standby buffer pin waits
JoongHyuk Shin <sjh910805@gmail.com>
From: JoongHyuk Shin <sjh910805@gmail.com>
To: "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2026-04-19T05:46:57Z
Lists: pgsql-hackers
Attachments
- 0001-Prevent-repeated-deadlock-check-signals-in-standby-b.patch (application/octet-stream) patch 0001
In ResolveRecoveryConflictWithBufferPin(), when deadlock_timeout fires, the function sends RECOVERY_CONFLICT_BUFFERPIN_DEADLOCK and returns. The caller (LockBufferForCleanup) loops back, sets up another deadlock_timeout, and the signal gets sent again every interval. The lock-conflict path had the same problem and was fixed in 8900b5a9d59a by adding a second ProcWaitForSignal() after the deadlock-check signal. The buffer-pin path was left with an XXX comment asking "should we fix this?". The attached patch applies the same fix: after sending the deadlock-check signal, reset got_standby_deadlock_timeout and call ProcWaitForSignal() so the startup process waits for UnpinBuffer() rather than looping and re-signaling. Patch attached.
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Fix race in ReplicationSlotRelease() for ephemeral slots
- f2081a7800f1 19 (unreleased) cited
-
Avoid leaking system path from pg_available_extensions
- db5ed03217b9 19 (unreleased) cited