Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVdVM-00041G-5X for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 17:36:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mVdVJ-0008LU-Vn for pgsql-hackers@arkaria.postgresql.org; Wed, 29 Sep 2021 17:36:25 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVdVJ-0008LM-0k for pgsql-hackers@lists.postgresql.org; Wed, 29 Sep 2021 17:36:25 +0000 Received: from new1-smtp.messagingengine.com ([66.111.4.221]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mVdVF-0004mh-1Y for pgsql-hackers@postgresql.org; Wed, 29 Sep 2021 17:36:24 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.nyi.internal (Postfix) with ESMTP id 7F586580F8F; Wed, 29 Sep 2021 13:36:18 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 29 Sep 2021 13:36:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:subject:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=eaP0SUP8JqpNUujEXCEK814BooLaFDpILMyTibvWFWE=; b=mYnGJiF3 9zICNtijEH7FtYn6P6v8V7DETf9UUbwqXkEtRhk64DiqXNGatJ2tzzwA+UZ3RoV9 Vhu9uSLq75JWpQQYV5SJfWa9QIygX7MpsotQGnyDgILabkWvzxiSiqeMs1R2eO8A 4bYvms3UkzUDVDnuGwzPxoCUmigrSksyMEFAIdX2toOQBV42DbTPmUqJ/eF9DiZm rNnQyspcsDEa95bnX+F2efKx3+oKLZuFNrHWmwCvUM6cmLkOZe85F8rT8HW6WE19 5GtagZXXniQkZ9vyqC14wQY6M6cA4lBdq9R2QzfxsORqUqltScvBPdxYe0z7N25v aMZeeyXU5F6uPQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudekvddgudduvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeev jedufeeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 29 Sep 2021 13:36:17 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id C1F822A06AB; Wed, 29 Sep 2021 14:36:14 -0300 (-03) Date: Wed, 29 Sep 2021 14:36:14 -0300 From: Alvaro Herrera To: Nitin Jadhav Cc: Robert Haas , Justin Pryzby , Michael Paquier , Bharath Rupireddy , Tom Lane , Andres Freund , Stephen Frost , Magnus Hagander , Thomas Munro , "pgsql-hackers@postgresql.org" Subject: Re: when the startup process doesn't (logging startup delays) Message-ID: <202109291736.w3lzq4prep3p@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk So, I've wondered about this part all along: > +/* > + * Calculates the timestamp at which the next timer should expire and enables > + * the timer accordingly. > + */ > +static void > +reset_startup_progress_timeout(TimestampTz now) > +{ > + TimestampTz next_timeout; > + > + next_timeout = TimestampTzPlusMilliseconds(scheduled_startup_progress_timeout, > + log_startup_progress_interval); > + if (next_timeout < now) > + { > + /* > + * Either the timeout was processed so late that we missed an > + * entire cycle or system clock was set backwards. > + */ > + next_timeout = TimestampTzPlusMilliseconds(now, log_startup_progress_interval); > + } > + > + enable_timeout_at(STARTUP_PROGRESS_TIMEOUT, next_timeout); Why is it that we set the next timeout to fire not at "now + interval" but at "when-it-should-have-fired-but-didn't + interval"? As a user, if I request a message to be logged every N milliseconds, and one of them is a little bit delayed, then (assuming I set it to 10s) I still expect the next one to occur at now+10s. I don't expect the next at "now+5s" if one is delayed 5s. In other words, I think this function should just be enable_timeout_after(STARTUP_PROGRESS_TIMEOUT, log_startup_progress_interval); This means you can remove the scheduled_startup_progress_timeout variable. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/ "No hay ausente sin culpa ni presente sin disculpa" (Prov. francés)