Re: when the startup process doesn't (logging startup delays) - Mailing list pgsql-hackers

From Robert Haas
Subject Re: when the startup process doesn't (logging startup delays)
Date
Msg-id CA+TgmoYq38i6iAzfRLVxA6Cm+wMCf4WM8wC3o_a+X_JvWC8bJg@mail.gmail.com
Whole thread Raw
In response to Re: when the startup process doesn't (logging startup delays)  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: when the startup process doesn't (logging startup delays)  (Nitin Jadhav <nitinjadhavpostgres@gmail.com>)
List 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 by date:

Previous
From: Asif Rehman
Date:
Subject: Re: Proposal: allow database-specific role memberships
Next
From: Robert Haas
Date:
Subject: Re: Correct error message for end-of-recovery record TLI