Re: pg_usleep for multisecond delays - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: pg_usleep for multisecond delays
Date
Msg-id 20230726234125.GA3560354@nathanxps13
Whole thread Raw
In response to Re: pg_usleep for multisecond delays  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: pg_usleep for multisecond delays
List pgsql-hackers
On Mon, Mar 13, 2023 at 02:16:31PM -0700, Nathan Bossart wrote:
> 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 started on the former approach (work-in-progress patch attached), but I
figured I'd ask whether folks are alright with this before I spend more
time on it.  Many of the sleeps in question are relatively short, are
intended for debugging, or are meant to prevent errors from repeating as
fast as possible, so I don't know if we should bother adding interrupt
handling support.

-- 
Nathan Bossart
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Gurjeet Singh
Date:
Subject: Re: There should be a way to use the force flag when restoring databases
Next
From: Nathan Bossart
Date:
Subject: Re: psql: Could we get "-- " prefixing on the **** QUERY **** outputs? (ECHO_HIDDEN)