Re: when the startup process doesn't (logging startup delays)

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, Justin Pryzby <pryzby(at)telsasoft(dot)com>, Michael Paquier <michael(at)paquier(dot)xyz>, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, Stephen Frost <sfrost(at)snowman(dot)net>, Magnus Hagander <magnus(at)hagander(dot)net>, Thomas Munro <thomas(dot)munro(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: when the startup process doesn't (logging startup delays)
Date: 2021-10-29 12:40:06
Message-ID: CA+TgmoaLm836G3YkCJm1qhkYu-BAro3dVXAjv1WJsRsOFj4pbg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Oct 29, 2021 at 7:37 AM Nitin Jadhav
<nitinjadhavpostgres(at)gmail(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeevan Ladhe 2021-10-29 12:58:24 Re: refactoring basebackup.c
Previous Message tomas 2021-10-29 12:14:35 plpgsql: can I use a variable in a DECLARE later whithin the DECLARE?