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

From Robert Haas
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CA+TgmoY8nd4b3xL_UrTvLMaYnWrC_Wgw-hp9cCbZxuzW1tSF1w@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)  (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>)
Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Tue, Oct 19, 2021 at 9:06 AM Nitin Jadhav
<nitinjadhavpostgres@gmail.com> wrote:
> Thanks for sharing the patch. Overall approach looks good to me. But
> just one concern about using enable_timeout_every() functionality. As
> per my understanding the caller should calculate the first scheduled
> timeout (now + interval) and pass it as the second argument but this
> is not the same in 'v2-0002-Quick-testing-hack.patch'. Anyways I have
> done the changes as I have mentioned (like now + interval). Kindly
> correct me if I am wrong. I am attaching 2 patches here.
> 'v19-0001-Add-enable_timeout_every-to-fire-the-same-timeout.patch' is
> the same as Robert's v2 patch. I have rebased my patch on top of this
> and it is 'v19-0002-startup-progress.patch'.

This version looks fine, so I have committed it (and my
enable_timeout_every patch also, as a necessary prerequisite).

Thanks,

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_dump versus ancient server versions
Next
From: Stephen Frost
Date:
Subject: Re: XTS cipher mode for cluster file encryption