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 1nc3sL-0002XG-8x for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2022 11:31:01 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nc3sK-000781-49 for pgsql-hackers@arkaria.postgresql.org; Wed, 06 Apr 2022 11:31:00 +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 1nc3sJ-00077s-R5 for pgsql-hackers@lists.postgresql.org; Wed, 06 Apr 2022 11:30:59 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nc3sG-00052h-TJ for pgsql-hackers@lists.postgresql.org; Wed, 06 Apr 2022 11:30:59 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id B6E3E5C006E; Wed, 6 Apr 2022 07:30:55 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 06 Apr 2022 07:30:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; bh=ndfuGAxwuAdNXwgNTeY+XetmwyqB5wvXJwSZ7Kb4rQg=; b=ZrqeOiUE 0T722qD9pIsROCatiW2qgXzs8R0fOlVzdMgdr+FZ0XgX6tj5k4oKT4ODOaOsouCT WFKZNqfAP+ER41XXR5EyerEiV7jCxPfu81V6M55FpCAjQqNu9+0cdq8IDGXje40F f0FwnCC/0ULFj2YFepp8nwE73Pm0BGCNIfYyh7605Z0+4TRayBqM4BXDMSln1qeX Yqs493Vf3Wyim3Tshb8GJ2VJQiET1DsxTdK5jZABmAZ496NPWa8YRSzA0NZTa8BW Vdg/lD3WxxPRSvkBzWDk588ZfM81lWdk4OpNbTMyign3Jzbc//UFkgHYGoNVQpCO U3IoCZq/HW+33Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudejiedggeduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvffukfggtggugfgjsehtkeertddttdejnecuhfhrohhmpeetlhhvrghr ohcujfgvrhhrvghrrgcuoegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhgqe enucggtffrrghtthgvrhhnpeefudelkeetiefggeeltddvvddvtdeludfgfefhtdeiveet fedtueeuheduuedvleenucffohhmrghinhepvghnthgvrhhprhhishgvuggsrdgtohhmpd hpohhsthhgrhgvshhqlhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgr mhepmhgrihhlfhhrohhmpegrlhhvhhgvrhhrvgesrghlvhhhrdhnohdqihhprdhorhhg X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 6 Apr 2022 07:30:55 -0400 (EDT) Received: by perhan.alvh.no-ip.org (Postfix, from userid 1000) id 2FE922A0FF5; Wed, 6 Apr 2022 07:31:31 -0400 (-04) Date: Wed, 6 Apr 2022 13:31:31 +0200 From: Alvaro Herrera To: Andres Freund Cc: Kyotaro Horiguchi , melanieplageman@gmail.com, Justin Pryzby , Thomas Munro , "David G. Johnston" , pgsql-hackers@lists.postgresql.org Subject: Re: shared-memory based stats collector - v70 Message-ID: <202204061131.lozz5n34d5w5@alvherre.pgsql> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220406030008.2qxipjxo776dwnqs@alap3.anarazel.de> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Just skimming a bit here ... On 2022-Apr-05, Andres Freund wrote: > From 0532b869033595202d5797b148f22c61e4eb4969 Mon Sep 17 00:00:00 2001 > From: Andres Freund > Date: Mon, 4 Apr 2022 16:53:16 -0700 > Subject: [PATCH v70 10/27] pgstat: store statistics in shared memory. > + PgStatsData > + Waiting fo shared memory stats data access > + Typo "fo" -> "for" > @@ -5302,7 +5317,9 @@ StartupXLOG(void) > performedWalRecovery = true; > } > else > + { > performedWalRecovery = false; > + } Why? :-) Why give pgstat_get_entry_ref the responsibility of initializing created_entry to false? The vast majority of callers don't care about that flag; it seems easier/cleaner to set it to false in pgstat_init_function_usage (the only caller that cares that I could find) before calling pgstat_prep_pending_entry. (I suggest pgstat_prep_pending_entry should have a comment line stating "*created_entry, if not NULL, is set true if the entry required to be created.", same as pgstat_get_entry_ref.) -- Álvaro Herrera PostgreSQL Developer — https://www.EnterpriseDB.com/ "How amazing is that? I call it a night and come back to find that a bug has been identified and patched while I sleep." (Robert Davidson) http://archives.postgresql.org/pgsql-sql/2006-03/msg00378.php