Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
От | Bossart, Nathan |
---|---|
Тема | Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep |
Дата | |
Msg-id | AD0B46DD-AD96-4D5C-85F5-1B987D86D83E@amazon.com обсуждение исходный текст |
Ответ на | Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Use WaitLatch for {pre, post}_auth_delay instead of pg_usleep
|
Список | pgsql-hackers |
On 7/28/21, 11:32 AM, "Tom Lane" <tgl@sss.pgh.pa.us> wrote: > I'm detecting a certain amount of lily-gilding here. Neither of these > delays are meant for anything except debugging purposes, and nobody as > far as I've heard has ever expressed great concern about identifying > which process they need to attach to for that purpose. So I think it > is a *complete* waste of time to add any cycles to connection startup > to make these delays more visible. > > I follow the idea of using WaitLatch to ensure that the delays are > interruptible by postmaster signals, but even that isn't worth a > lot given the expected use of these things. I don't see a need to > expend any extra effort on wait-reporting. +1. The proposed patch doesn't make the delay visibility any worse than what's already there. Nathan
В списке pgsql-hackers по дате отправления: