Re: pg_usleep for multisecond delays

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