Disable startup progress timeout during standby WAL replay

The server disables periodic recovery progress logging controlled by
log_startup_progress_interval in standby mode, because a standby
remains in recovery until promotion and would otherwise emit recovery
progress messages indefinitely.

However, startup operations executed afterward, such as
ResetUnloggedRelations(), can re-enable the startup progress timeout.
As a result, the timeout could previously remain active during standby
WAL replay.

This caused no user-visible issue because recovery progress messages
are not emitted during standby WAL replay. However, the timeout still
generated unnecessary periodic wakeups.

Fix this by disabling the startup progress timeout again when WAL
replay starts in standby mode. This preserves progress reporting for
earlier startup operations while keeping the timeout disabled during
standby WAL replay as intended.

Also clarify the log_startup_progress_interval documentation to
describe which startup operations emit progress messages, and that WAL
replay progress is not reported on standby servers.

Author: MasaoFujii

doc/src/sgml/config.sgml

@@ -7661,7 +7661,9 @@ local0.*    /var/log/postgresql
          operation. The default is 10 seconds. A setting of <literal>0</literal>
          disables the feature.  If this value is specified without units,
          it is taken as milliseconds.  This setting is applied separately to
-         each operation.
+         each operation, such as WAL replay, syncing the data
+         directory, and resetting unlogged relations.  On a standby server,
+         however, it does not apply during WAL replay.
          This parameter can only be set in the <filename>postgresql.conf</filename>
          file or on the server command line.
         </para>

src/backend/access/transam/xlogrecovery.c

@@ -1669,6 +1669,18 @@ PerformWalRecovery(void)
 	 */
 	CheckRecoveryConsistency();
 
+	/*
+	 * EnableStandbyMode() disables periodic recovery progress logging,
+	 * because a standby remains in recovery until promotion and would
+	 * otherwise emit recovery progress messages indefinitely.
+	 *
+	 * However, earlier startup phases executed afterward, such as
+	 * ResetUnloggedRelations(), may have re-enabled the timeout. Therefore,
+	 * disable it again before entering WAL replay.
+	 */
+	if (StandbyMode)
+		disable_startup_progress_timeout();
+
 	/*
 	 * Find the first record that logically follows the checkpoint --- it
 	 * might physically precede it, though.