Hi, On 2026-09-21 10:25:12 -0400, shihao zhong wrote: > Thanks for the patch. This is the same problem as BUG #19622, and > Alexandre has a sinval based patch for it in [1]. > > I read v1, the placement looks good to me. > > For the never idle case you named, the check could go after the > if/else, next to CHECK_FOR_INTERRUPTS().
I'm doubtful that that'd be a good idea. It'd add a lot of contention on the CheckpointerShmem->ckpt_lck that's acquired as part of FirstCallSinceLastCheckpoint. On a system with a lot of IO that'd probably noticeable. I don't think any approach that adds an acuisition of a central lock around every IO is going to make sense here. I think Alexandre's patch has the same issue, unfortunately. I'm sure we could make FirstCallSinceLastCheckpoint() not require a spinlock. But I wonder if that's quite the right design. Doing work for every single iteration of various loops (bgwriter, io worker) doesn't really seem right to me for something that's as rare as this. Having aux processes participate in sinval doesn't really clearly seem like the right thing either. There are a lot of messages that they never benefit from. And manual filtering in the receive function like Alexandre added doesn't really seem like a good way of addressing that. Maybe we should just drop having SHAREDINVALSMGR_ID and only use PROCSIGNAL_BARRIER_SMGRRELEASE? Greetings, Andres Freund
