Re: when the startup process doesn't (logging startup delays)
От | Kyotaro Horiguchi |
---|---|
Тема | Re: when the startup process doesn't (logging startup delays) |
Дата | |
Msg-id | 20221121.112000.896907652962800511.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | 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)
|
Список | pgsql-hackers |
At Fri, 18 Nov 2022 15:55:00 +0530, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com> wrote in > On Fri, Nov 18, 2022 at 12:42 AM Robert Haas <robertmhaas@gmail.com> wrote: > > > > On Thu, Nov 17, 2022 at 2:22 AM Bharath Rupireddy > > <bharath.rupireddyforpostgres@gmail.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
В списке pgsql-hackers по дате отправления: