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

At Fri, 18 Nov 2022 15:55:00 +0530, Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote in
> On Fri, Nov 18, 2022 at 12:42 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> >
> > On Thu, Nov 17, 2022 at 2:22 AM Bharath Rupireddy
> > <bharath(dot)rupireddyforpostgres(at)gmail(dot)com> wrote:
> > > Duplication is a problem that I agree with and I have an idea here -
> > > how about introducing a new function, say EnableStandbyMode() that
> > > sets StandbyMode to true and disables the startup progress timeout,
> > > something like the attached?
> >
> > That works for me, more or less. But I think that
> > enable_startup_progress_timeout should be amended to either say if
> > (log_startup_progress_interval == 0 || StandbyMode) return; or else it
> > should at least Assert(!StandbyMode), so that we can't accidentally
> > re-enable the timer after we shut it off.
>
> Hm, an assertion may not help in typical production servers running on
> non-assert builds. I've modified the if condition, please see the
> attached v5 patch.

I prefer Robert's approach as it is more robust for future changes and
simple. I prefer to avoid this kind of piggy-backing and it doesn't
seem to be needed in this case. XLogShutdownWalRcv() looks like a
similar case to me and honestly I don't like it in the sense of
robustness but it is simpler than checking walreceiver status at every
site that refers to the flag.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center