Re: pg_usleep for multisecond delays

From: "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_usleep for multisecond delays
Date: 2023-04-03 20:33:27
Message-ID: CAM-w4HMd41-LovbqNUz77M32UkgOfwAOy3zva2pt7BqQvqHEKQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, 13 Mar 2023 at 17:17, Nathan Bossart <nathandbossart(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2023-04-03 20:50:43 Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)
Previous Message Gregory Stark (as CFM) 2023-04-03 20:30:52 Re: Removing unneeded self joins