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

Michael Paquier <michael@paquier.xyz>

From: Michael Paquier <michael@paquier.xyz>
To: Justin Pryzby <pryzby@telsasoft.com>
Cc: Nitin Jadhav <nitinjadhavpostgres@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>, Stephen Frost <sfrost@snowman.net>, Magnus Hagander <magnus@hagander.net>, Thomas Munro <thomas.munro@gmail.com>, pgsql-hackers@postgresql.org
Date: 2021-09-07T05:28:16Z
Lists: pgsql-hackers
On Fri, Sep 03, 2021 at 09:23:27PM -0500, Justin Pryzby wrote:
> On Fri, Sep 03, 2021 at 01:23:56PM +0530, Nitin Jadhav wrote:
> > Please find the updated patch attached.
> 
> Please check CA+TgmoZtbqxaOLdpNkBcDbz=41tWALA8kpH4M=RWtPYHC7-KNg@mail.gmail.com
> 
> I agree with Robert that a standby server should not continuously show timing
> messages for WAL replay.

Clearly.  This should be limited to crash recovery, and maybe there
could be some checks to make sure that nothing is logged once a
consistent point is reached.  Honestly, I don't see why we should have
a GUC for what's proposed here.  A value too low would bloat the logs
with entries that are not that meaningful.  A value too large would
just prevent access to some information wanted.  Wouldn't it be better
to just pick up a value like 10s or 20s?

Looking at v13..

+       {"log_startup_progress_interval", PGC_SIGHUP, LOGGING_WHEN,
+           gettext_noop("Sets the time interval between each progress update "
+                        "of the startup process."),
+           gettext_noop("0 logs all messages. -1 turns this feature off."),
+           GUC_UNIT_MS,
The unit is incorrect here, as that would default to 10ms, contrary to
what the documentation says about 10s.
--
Michael

Commits

  1. Un-revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  2. Revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."

  3. Disable STARTUP_PROGRESS_TIMEOUT in standby mode.

  4. Fix race condition in startup progress reporting.

  5. Report progress of startup operations that take a long time.

  6. Add enable_timeout_every() to fire the same timeout repeatedly.