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

On Mon, Nov 14, 2022 at 7:37 AM Simon Riggs
<simon(dot)riggs(at)enterprisedb(dot)com> wrote:
> > Whilte at it, I noticed that we report redo progress for PITR, but we
> > don't report when standby enters archive recovery mode, say due to a
> > failure in the connection to primary or after the promote signal is
> > found. Isn't it useful to report in this case as well to know the
> > recovery progress?
>
> I think your patch disables progress too early, effectively turning
> off the standby progress feature. The purpose was to report on things
> that take long periods during recovery, not just prior to recovery.
>
> I would advocate that we disable progress only while waiting, as I've done here:
> https://www.postgresql.org/message-id/CANbhV-GcWjZ2cmj0uCbZDWQUHnneMi_4EfY3dVWq0-yD5o7Ccg%40mail.gmail.com

Maybe I'm confused here, but I think that, on a standby, startup
progress messages are only printed until the main redo loop is
reached. Otherwise, we would print a message on a standby every 10s
forever, which seems like a thing that most users would not like. So I
think that Bharath has the right idea here.

I don't think that his patch is right in detail, though. I don't think
the call to disable_timeout() needs to be conditional, and I don't
think the Assert is correct. Also, I think that your patch has the
right idea in encapsulating the disable_timeout() call inside a new
function disable_startup_progress_timeout(), rather than having the
details known directly by xlogrecovery.c.

--
Robert Haas
EDB: http://www.enterprisedb.com