Re: when the startup process doesn't (logging startup delays)
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Nitin Jadhav <nitinjadhavpostgres@gmail.com>
Cc: Justin Pryzby <pryzby@telsasoft.com>,
Michael Paquier <michael@paquier.xyz>, 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>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2021-09-27T15:49:59Z
Lists: pgsql-hackers
On Mon, Sep 27, 2021 at 7:26 AM Nitin Jadhav <nitinjadhavpostgres@gmail.com> wrote: > > I really don't know what to say about this. You say that the time is > > measured in milliseconds, and then immediately turn around and say > > "For example, if you set it to 10s". Now we do expect that most people > > will set it to intervals that are measured in seconds rather than > > milliseconds, but saying that setting it to a value measured in > > seconds is an example of setting it in milliseconds is not logical. > > Based on the statement "I suggest making the GUC GUC_UNIT_MS rather > than GUC_UNIT_S, but expressing the default in postgresl.conf.sample > as 10s rather than 10000ms", I have used the default value in the > postgresl.conf.sample as 10s rather than 10000ms. So I just used the > same value in the example too in config.sgml. If it is really getting > confusing, I will change it to 100ms in config.sgml. That's really not what I'm complaining about. I think if we're going to give an example at all, 10ms is a better example than 100ms, because 10s is a value that people are more likely to find useful. But I'm not sure that it's necessary to mention a specific value, and if it is, I think it needs to be phrased in a less confusing way. > Made changes which indicate 0 mean disabled, > 0 mean interval in > millisecond and removed -1. Well, I see that -1 is now disallowed, and that's good as far as it goes, but 0 still does not actually disable the feature. I don't understand why you posted the previous version of the patch without testing that it works, and I even less understand why you are posting another version without fixing the bug that I pointed out to you in the last version. -- 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