On Mon, Oct 25, 2021 at 9:26 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Oct 19, 2021 at 9:06 AM Nitin Jadhav > <nitinjadhavpostg...@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.
