Re: when the startup process doesn't (logging startup delays)
От | Robert Haas |
---|---|
Тема | Re: when the startup process doesn't (logging startup delays) |
Дата | |
Msg-id | CA+TgmoYq38i6iAzfRLVxA6Cm+wMCf4WM8wC3o_a+X_JvWC8bJg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: when the startup process doesn't (logging startup delays) (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: when the startup process doesn't (logging startup delays)
|
Список | pgsql-hackers |
On Mon, Oct 25, 2021 at 11:56 AM Robert Haas <robertmhaas@gmail.com> wrote: > This version looks fine, so I have committed it (and my > enable_timeout_every patch also, as a necessary prerequisite). I was fooling around with a test setup today, working on an unrelated problem, and this happened: 2021-10-28 14:21:23.145 EDT [92010] LOG: resetting unlogged relations (init), elapsed time: 0.00 s, current path: base/13020 That's not supposed to happen. I assume the problem is that the timeout for the previous phase fired just as we were beginning a new one, and the code got confused. I think we probably need to do something like this to make sure that the timeout from one operation can't trigger a log message for the next: diff --git a/src/backend/postmaster/startup.c b/src/backend/postmaster/startup.c index 28e68dd871..47ec737888 100644 --- a/src/backend/postmaster/startup.c +++ b/src/backend/postmaster/startup.c @@ -320,6 +320,8 @@ begin_startup_progress_phase(void) if (log_startup_progress_interval == 0) return; + disable_timeout(STARTUP_PROGRESS_TIMEOUT, false); + startup_progress_timer_expired = false; startup_progress_phase_start_time = GetCurrentTimestamp(); fin_time = TimestampTzPlusMilliseconds(startup_progress_phase_start_time, log_startup_progress_interval); Thoughts? -- Robert Haas EDB: http://www.enterprisedb.com
В списке pgsql-hackers по дате отправления: