On Tue, Jun 16, 2026 at 5:28 PM Kyotaro Horiguchi <[email protected]> wrote: > I see the point about the standby.signal case, where WAL replay may > already be in progress when EnableStandbyMode() is reached. In fact, > that example makes me think the opposite: it seems that > EnableStandbyMode() only needs to disable the timeout in this > particular case because replay has already started before it is > called. > > The other call sites do not seem to share that property, and it looks > to me as though the timeout could still be legitimately needed there > until standby replay actually begins. That is the reason behind my > earlier comment questioning whether EnableStandbyMode() is the right > place to disable it.
Maybe I'm missing your point... Could you clarify what change you are suggesting for EnableStandbyMode() itself? > Similarly, if the timeout should be disabled before reading the first > WAL record, I wonder whether begin_startup_progress_phase() should > also be called at the same point. begin_startup_progress_phase() is currently called at the same point where we emit the "redo starts at ..." log message, which seems like a natural and consistent boundary for WAL replay progress reporting. So it seems better not to change where begin_startup_progress_phase() is called. On second thought, for disable_startup_progress_timeout(), calling it at the same place as begin_startup_progress_phase(), or before reading the first WAL record, seems effectively equivalent from the perspective of user-visible WAL replay progress logging in standby mode. The practical difference, as far as I can see, is only whether the startup progress timeout can still fire while reading the first WAL record. Reading that first record can potentially take some time, for example while waiting for WAL to arrive or restoring it from archive. If we want to suppress timeout activity during that period as well, it seems better to call disable_startup_progress_timeout() before reading the first WAL record. Regards, -- Fujii Masao
