On Mon, Nov 14, 2022 at 7:37 AM Simon Riggs <simon.ri...@enterprisedb.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