On Fri, Mar 10, 2023 at 12:28:28PM -0500, Tom Lane wrote: > A quick grep for pg_usleep with large intervals finds rather more > than you touched: > > [...] > > Did you have reasons for excluding the rest of these?
I'm still looking into each of these, but my main concerns were 1) ensuring latch support had been set up and 2) figuring out the right interrupt function to use. Thus far, I don't think latch support is a problem because InitializeLatchSupport() is called quite early. However, I'm not as confident with the interrupt functions yet. Some of these multisecond sleeps are done very early before the signal handlers are set up. Others are done within the sigsetjmp() block. And at least one is in a code path that both the startup process and single-user mode touch. At the moment, I'm thinking about either removing the check_interrupts function pointer argument altogether or making it optional for code paths where we might not want any interrupt handling to run. In the former approach, we could simply call WaitLatch() without a latch. While this wouldn't do any interrupt handling, we'd still get custom wait event support and better responsiveness when the postmaster dies, which is strictly better than what's there today. And many of these sleeps are in uncommon or debug paths, so delaying interrupt handling might be okay. In the latter approach, we would have interrupt handling, but I'm worried that would be easy to get wrong. I think it would be nice to have interrupt handling if possible, so I'm still (over)thinking about this. I agree with the rest of your comments. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com