On Mon, Oct 25, 2021 at 9:26 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> 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 for getting this in.
I have few more thoughts:
Can we also log the total time the startup process took to recover,
and also the total time each stage of the recovery/redo processing
took: 1) into a file or 2) emitting that info via a new hook 3) into a
system catalog table (assuming at the end of the recovery the database
is in a consistent state, but I'm not sure if we ever update any
catalog tables in/after the startup/recovery phase).
This will help the users/admins/developers for summarizing, analytical
and debugging purposes. This information can easily help us to
understand the recovery patterns.
Thoughts?
If okay, I can spend some more time and start a separate thread to discuss.
Regards,
Bharath Rupireddy.
