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 1mUtnF-0004Ug-0x for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Sep 2021 16:47:53 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1mUtnD-0001jn-Cm for pgsql-hackers@arkaria.postgresql.org; Mon, 27 Sep 2021 16:47:51 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mUtnC-0001ja-J8 for pgsql-hackers@lists.postgresql.org; Mon, 27 Sep 2021 16:47:51 +0000 Received: from wnew1-smtp.messagingengine.com ([64.147.123.26]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mUtn7-00017X-Li for pgsql-hackers@postgresql.org; Mon, 27 Sep 2021 16:47:49 +0000 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailnew.west.internal (Postfix) with ESMTP id 8839D2B01374; Mon, 27 Sep 2021 12:47:42 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Mon, 27 Sep 2021 12:47:43 -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=Bau8ajIoM110HL2L2RysWhh8B02Mi1UQjXB5lSmOfN8=; b=gkyQZ5tc 4M38gPDSkSP78dlXj7IITsuqAyLdeSKCrXOpdR/XIYDRz9F3ok/TOtc/LevVWqWH 6UM+rN1rAntYFM8foUbTQouB6lwX6Nhi0QAGq4+gJcIHRspTeGvyF+xd0a3TsYBe bylotiS6oxQFJ36ToDwjSQkgQI8/d+xxb58ollSrFPBNfsjqfhvog5VHbSehA1ul Rujp+AcUpfQQB9rOMM7axlIlkY20aIWkNoyxDVdRT5OZxaEqtvNbhogQZ7Gu/UnD RZCtPZ9cAIZwHom8OvmmxUAP87T1Z3t+r18jpun1NjM85XZ7ZLOGXtfUHPjzFbhM zjVInhxgrNoysQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrudejkedguddtvdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvuffkgggtugfgjgesthekredttddtjeenucfhrhhomheptehlvhgr rhhoucfjvghrrhgvrhgruceorghlvhhhvghrrhgvsegrlhhvhhdrnhhoqdhiphdrohhrgh eqnecuggftrfgrthhtvghrnhepudejveejffejveduudetvdekieeuiedtvdeileefkeev jedufeeguedvjefhueelnecuffhomhgrihhnpegvnhhtvghrphhrihhsvggusgdrtghomh enucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegrlhhv hhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 27 Sep 2021 12:47:40 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 2B86F2A0677; Mon, 27 Sep 2021 13:47:38 -0300 (-03) Date: Mon, 27 Sep 2021 13:47:38 -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 , Pg Hackers Subject: Re: when the startup process doesn't (logging startup delays) Message-ID: <202109271647.frp35okoz4ou@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 > +/* > + * Decides whether to log the startup progress or not based on whether the > + * timer is expired or not. Returns FALSE if the timer is not expired, otherwise > + * calculates the elapsed time and sets the respective out parameters secs and > + * usecs. Enables the timer for the next log message and returns TRUE. > + */ > +bool > +startup_progress_timeout_has_expired(long *secs, int *usecs) I think this comment can be worded better. It says it "decides", but it doesn't actually decide on any action to take -- it just reports whether the timer expired or not, to allow its caller to make the decision. In such situations we just say something like "Report whether startup progress has caused a timeout, return true and rearm the timer if it did, or just return false otherwise"; and we don't indicate what the value is going to be used *for*. Then the caller can use the boolean return value to make a decision, such as whether something is going to be logged. This function can be oblivious to details such as this: > + /* If the timeout has not occurred, then no need to log the details. */ > + if (!startup_progress_timer_expired) > + return false; here we can just say "No timeout has occurred" and make no inference about what's going to happen or not happen. Also, for functions that do things like this we typically use English sentence structure with the function name starting with the verb -- perhaps has_startup_progress_timeout_expired(). Sometimes we are lax about this if we have some sort of poor-man's modularisation by using a common prefix for several functions doing related things, which perhaps could be "startup_progress_*" in your case, but your other functions are already not doing that (such as begin_startup_progress_phase) so it's not clear why you would not use the most natural name for this one. > + ereport_startup_progress("syncing data directory (syncfs), elapsed time: %ld.%02d s, current path: %s", > + path); Please make sure to add ereport_startup_progress() as a translation trigger in src/backend/nls.mk. -- Álvaro Herrera 39°49'30"S 73°17'W — https://www.EnterpriseDB.com/