Re: when the startup process doesn't (logging startup delays)
От | Nitin Jadhav |
---|---|
Тема | Re: when the startup process doesn't (logging startup delays) |
Дата | |
Msg-id | CAMm1aWY790RiVtS2gKBXUmH3FOs57nCG8pQCdJSV+Qb+0MLH6g@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: when the startup process doesn't (logging startup delays) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: when the startup process doesn't (logging startup delays)
|
Список | pgsql-hackers |
> I think you're wrong. If we did that, the previous timer could fire > right after we set startup_progress_timer_expired = false, and before > we reschedule the timeout. It seems annoying to have to disable the > timeout and immediately turn around and re-enable it, but I don't see > how to avoid the race condition otherwise. Right. There is a possibility of race conditions. In that case the above changes look good to me. Thanks & Regards, Nitin Jadhav On Fri, Oct 29, 2021 at 6:10 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Fri, Oct 29, 2021 at 7:37 AM Nitin Jadhav > <nitinjadhavpostgres@gmail.com> wrote: > > ereport_startup_progress() logs a message. So I feel just setting > > 'startup_progress_timer_expired' to false in > > begin_startup_progress_phase() would work. Please correct me if I am > > wrong. > > I think you're wrong. If we did that, the previous timer could fire > right after we set startup_progress_timer_expired = false, and before > we reschedule the timeout. It seems annoying to have to disable the > timeout and immediately turn around and re-enable it, but I don't see > how to avoid the race condition otherwise. > > -- > Robert Haas > EDB: http://www.enterprisedb.com > >
В списке pgsql-hackers по дате отправления: