Re: when the startup process doesn't (logging startup delays)
Nitin Jadhav <nitinjadhavpostgres@gmail.com>
From: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Justin Pryzby <pryzby@telsasoft.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" <pgsql-hackers@postgresql.org>
Date: 2021-07-30T05:10:36Z
Lists: pgsql-hackers
> Thanks. Can you please have a look at what I suggested down toward the > bottom of http://postgr.es/m/CA+TgmoaP2wEFSktmCgwT9LXuz7Y99HNdUYshpk7qNFuQB98g6g@mail.gmail.com > ? > > If we're going to go the route of combining the functions, I agree > that a Boolean is the way to go; I think we have some existing > precedent for 'bool finished' rather than 'bool done'. > > But I kind of wonder if we should have an enum in the first place. It > feels like we've got code in a bunch of places that just exists to > decide which enum value to use, and then code someplace else that > turns around and decides which message to produce. That would be > sensible if we were using the same enum values in lots of places, but > that's not the case here. So suppose we just moved the messages to the > places where we're now calling LogStartupProgress() or > LogStartupProgressComplete()? So something like this: Sorry. I thought it is related to the discussion of deciding whether LogStartupProgress() and LogStartupProgressComplete() should be combined or not. I feel it's a really nice design. With this we avoid a "action at a distance" issue and its easy to use. If we are reporting the same kind of msgs at multiple places then the current approach of using enum will be more suitable since we don't have to worry about matching the log msg string. But in the current scenario, we are not using the same kind of msgs at multiple places (I feel such scenario will not occur in future also. Even if there is similar operation, it can be distinguished like resetting unlogged relations is distinguished by init and clean. Kindly mention if you can oversee any such scenario), hence the approach you are suggesting will be a best suit. Thanks & Regards, Nitin Jadhav On Thu, Jul 29, 2021 at 9:48 PM Robert Haas <robertmhaas@gmail.com> wrote: > > On Thu, Jul 29, 2021 at 4:56 AM Nitin Jadhav > <nitinjadhavpostgres@gmail.com> wrote: > > Thanks for sharing the information. I have done the necessary changes > > to show the logs during the latter case (postgres --single) and > > verified the log messages. > > Thanks. Can you please have a look at what I suggested down toward the > bottom of http://postgr.es/m/CA+TgmoaP2wEFSktmCgwT9LXuz7Y99HNdUYshpk7qNFuQB98g6g@mail.gmail.com > ? > > -- > Robert Haas > EDB: http://www.enterprisedb.com
Commits
-
Un-revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."
- ecb01e6ebb5a 15.3 landed
-
Revert "Disable STARTUP_PROGRESS_TIMEOUT in standby mode."
- 1eadfbdd7eb0 15.2 landed
-
Disable STARTUP_PROGRESS_TIMEOUT in standby mode.
- 98e7234242a6 15.2 landed
- 8a2f783cc489 16.0 landed
-
Fix race condition in startup progress reporting.
- 5ccceb2946d4 15.0 landed
-
Report progress of startup operations that take a long time.
- 9ce346eabf35 15.0 landed
-
Add enable_timeout_every() to fire the same timeout repeatedly.
- 732e6677a667 15.0 landed