Re: pg_usleep for multisecond delays
От | Gregory Stark (as CFM) |
---|---|
Тема | Re: pg_usleep for multisecond delays |
Дата | |
Msg-id | CAM-w4HMd41-LovbqNUz77M32UkgOfwAOy3zva2pt7BqQvqHEKQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pg_usleep for multisecond delays (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_usleep for multisecond delays
|
Список | 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 по дате отправления: