Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSMmk-00DJ91-Jx for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 19:50:15 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1rSMmj-00G3bs-Ij for pgsql-hackers@arkaria.postgresql.org; Tue, 23 Jan 2024 19:50:13 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSMmj-00G3bO-9q for pgsql-hackers@lists.postgresql.org; Tue, 23 Jan 2024 19:50:13 +0000 Received: from out2-smtp.messagingengine.com ([66.111.4.26]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1rSMmg-0030rm-TJ for pgsql-hackers@postgresql.org; Tue, 23 Jan 2024 19:50:12 +0000 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 537A15C00F1; Tue, 23 Jan 2024 14:50:10 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 23 Jan 2024 14:50:10 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=anarazel.de; h= cc:cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1706039410; x=1706125810; bh=snXGTkNLak K4/UzyjtjIClilnHznQ6MCz0Zwi+J0hKk=; b=ZLCgflMm6ghgjwQbvPrToEGunS y8qWkMxHnK6Hsd3EahijFpLpg0lb/FNYd0IlmfmdTLOJ/uaoiEV/wF9m655OcTWd gB6H2mDoOKjwTUNl1/juqWnvoToqVasXMmMqWmcfaGk4hW+SXvxHLGrhd5Qcnl6w e76zIYcyLXNkxM9025vyAG30nl4UB3EkX7u3bRwttCsD6XlnYojUcydEfTEsa9OI m163JW8xgKzVjb/3Z5+iXSdK8Vlhr/vIYFtsEhtcwMmkHzOI66J+6bRv5nkWvIz0 4bf5/ev1xLPDr2vGgfhFY30ujoDMmpJ/WU0KWR7+5xP50v9Tcx89EKzLIwNg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1706039410; x=1706125810; bh=snXGTkNLakK4/UzyjtjIClilnHzn Q6MCz0Zwi+J0hKk=; b=W/PuV4Yi+YGsdVpYjde3LWeop+EqYPLzOEX9GKIZzDoa gyaKbrdCLFBCrzBb/Bbrt9yRUShm1n4QWT60j6TzGLx+OsX9v8gi6YGC22R9ELHW yuQbJMf//WL6KQMc3bqvVNzQOOFwNse4spMmEA1OIr3tPrsWC/9oz6n4qRzXYKcs exhAKgdOt6uKIsx9WIUHjWefqdHCNXk7d7X235+jX5vUXMDq8IVcmxAu/UCV8Sak bJ3nMoZfn7zgTbQX0lICfdHCwpxmeGhZyeMTe2BgALcA9bBIkxpTI/aoM5kKEX4r pGOPM7rnfFMezFdkNpj9vqcYBNOcz4A4JCCwnhPLCQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrvdekkedguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpeffhffvvefukfhfgggtuggjsehttdertddttddvnecuhfhrohhmpeetnhgu rhgvshcuhfhrvghunhguuceorghnughrvghssegrnhgrrhgriigvlhdruggvqeenucggtf frrghtthgvrhhnpedvffefvefhteevffegieetfefhtddvffejvefhueetgeeludehteev udeitedtudenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpegrnhgurhgvshesrghnrghrrgiivghlrdguvg X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 23 Jan 2024 14:50:10 -0500 (EST) Date: Tue, 23 Jan 2024 11:50:09 -0800 From: Andres Freund To: Heikki Linnakangas Cc: Tristan Partin , pgsql-hackers , Thomas Munro Subject: Re: Refactoring backend fork+exec code Message-ID: <20240123195009.44wtutga24p5sh3s@awork3.anarazel.de> References: <7a59b073-5b5b-151e-7ed3-8b01ff7ce9ef@iki.fi> <20230710225043.svl7fqxecwshwc7a@awork3.anarazel.de> <119551e6-60f6-49b2-ae04-a382a89f900c@iki.fi> <20231130202648.7k6agmuizdilufnv@awork3.anarazel.de> <59527c9b-c3f7-4d0c-a3f1-00d0ed5cc186@iki.fi> <20240122210740.7vq5fd4woixpwx3f@awork3.anarazel.de> <8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8171f1aa-496f-46a6-afc3-c46fe7a9b407@iki.fi> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2024-01-23 21:07:08 +0200, Heikki Linnakangas wrote: > On 22/01/2024 23:07, Andres Freund wrote: > > > diff --git a/src/backend/utils/activity/backend_status.c b/src/backend/utils/activity/backend_status.c > > > index 1a1050c8da1..92f24db4e18 100644 > > > --- a/src/backend/utils/activity/backend_status.c > > > +++ b/src/backend/utils/activity/backend_status.c > > > @@ -257,17 +257,16 @@ pgstat_beinit(void) > > > else > > > { > > > /* Must be an auxiliary process */ > > > - Assert(MyAuxProcType != NotAnAuxProcess); > > > + Assert(IsAuxProcess(MyBackendType)); > > > /* > > > * Assign the MyBEEntry for an auxiliary process. Since it doesn't > > > * have a BackendId, the slot is statically allocated based on the > > > - * auxiliary process type (MyAuxProcType). Backends use slots indexed > > > - * in the range from 0 to MaxBackends (exclusive), so we use > > > - * MaxBackends + AuxProcType as the index of the slot for an auxiliary > > > - * process. > > > + * auxiliary process type. Backends use slots indexed in the range > > > + * from 0 to MaxBackends (exclusive), and aux processes use the slots > > > + * after that. > > > */ > > > - MyBEEntry = &BackendStatusArray[MaxBackends + MyAuxProcType]; > > > + MyBEEntry = &BackendStatusArray[MaxBackends + MyBackendType - FIRST_AUX_PROC]; > > > } > > > > Hm, this seems less than pretty. It's probably ok for now, but it seems like a > > better fix might be to just start assigning backend ids to aux procs or switch > > to indexing by pgprocno? > > Using pgprocno is a good idea. Come to think of it, why do we even have a > concept of backend ID that's separate from pgprocno? backend ID is used to > index the ProcState array, but AFAICS we could use pgprocno as the index to > that, too. I think we should do that. There are a few processes not participating in sinval, but it doesn't make enough of a difference to make sinval slower. And I think there'd be far bigger efficiency improvements to sinvaladt than not having a handful more entries. Greetings, Andres Freund