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  (Nathan Bossart <nathandbossart@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: "Gregory Stark (as CFM)"
Дата:
Сообщение: Re: Removing unneeded self joins
Следующее
От: Melanie Plageman
Дата:
Сообщение: Re: pg_stat_bgwriter.buffers_backend is pretty meaningless (and more?)