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

From Gregory Stark (as CFM)
Subject Re: pg_usleep for multisecond delays
Date
Msg-id CAM-w4HMd41-LovbqNUz77M32UkgOfwAOy3zva2pt7BqQvqHEKQ@mail.gmail.com
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, 13 Mar 2023 at 17:17, Nathan Bossart <nathandbossart@gmail.com> wrote:
>
> 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.

Is this still a WIP? Is it targeting this release? There are only a
few days left before the feature freeze. I'm guessing it should just
move to the next CF for the next release?



-- 
Gregory Stark
As Commitfest Manager



pgsql-hackers by date:

Previous
From: "Gregory Stark (as CFM)"
Date:
Subject: Re: Removing unneeded self joins
Next
From: Melanie Plageman
Date:
Subject: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)