Re: pg_usleep for multisecond delays
От | Nathan Bossart |
---|---|
Тема | Re: pg_usleep for multisecond delays |
Дата | |
Msg-id | 20230726234125.GA3560354@nathanxps13 обсуждение исходный текст |
Ответ на | Re: pg_usleep for multisecond delays (Nathan Bossart <nathandbossart@gmail.com>) |
Ответы |
Re: pg_usleep for multisecond delays
|
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: