Thanks for the review. v2 attached, with the suggested initialization added for symmetry.
Agreed this is an improvement rather than a bug fix, so I've updated the CF tag to Performance accordingly. I also verified the fix locally on a primary-standby setup, using the buffer-pin conflict scenario from src/test/recovery/t/ 031_recovery_conflict.pl (aborted INSERT + cursor on standby + VACUUM FREEZE on primary). On master, strace showed 9 SIGUSR1 broadcasts to the conflicting backend over a 10-second window (one per deadlock_timeout). With the patch applied, only 1 broadcast over the same window. Patch attached. -- JoongHyuk Shin On Tue, Apr 21, 2026 at 2:55 PM Michael Paquier <[email protected]> wrote: > On Tue, Apr 21, 2026 at 02:42:38PM +0900, Fujii Masao wrote: > > Since this change improves recovery-conflict behavior rather than fixing > a bug, > > it doesn't seem to need backpatching and we may need to wait until v20 > > development opens (probably July) before committing it. > > Yeah, this one is an improvement, not an actual bug, so let's wait for > v20 if worth doing (I did not check it). > -- > Michael >
v2-0001-Prevent-repeated-deadlock-check-signals-in-standb.patch
Description: Binary data
