Re: when the startup process doesn't (logging startup delays)
От | Michael Paquier |
---|---|
Тема | Re: when the startup process doesn't (logging startup delays) |
Дата | |
Msg-id | YTb4cDKWaAKfoTMM@paquier.xyz обсуждение исходный текст |
Ответ на | Re: when the startup process doesn't (logging startup delays) (Justin Pryzby <pryzby@telsasoft.com>) |
Ответы |
Re: when the startup process doesn't (logging startup delays)
Re: when the startup process doesn't (logging startup delays) |
Список | 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
Вложения
В списке pgsql-hackers по дате отправления: