Re: when the startup process doesn't (logging startup delays) - Mailing list pgsql-hackers

From Nitin Jadhav
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CAMm1aWY790RiVtS2gKBXUmH3FOs57nCG8pQCdJSV+Qb+0MLH6g@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
List 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 by date:

Previous
From: Jeevan Ladhe
Date:
Subject: Re: refactoring basebackup.c
Next
From: Robert Haas
Date:
Subject: Re: ThisTimeLineID is used uninitialized in basebackup.c, too