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 1r8sYQ-00CI9t-R7 for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2023 01:42:55 +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 1r8sYP-004Mhx-36 for pgsql-hackers@arkaria.postgresql.org; Fri, 01 Dec 2023 01:42:53 +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 1r8sYN-004Mgm-7B for pgsql-hackers@lists.postgresql.org; Fri, 01 Dec 2023 01:42:52 +0000 Received: from out3-smtp.messagingengine.com ([66.111.4.27]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1r8sYK-008CAR-1D for pgsql-hackers@postgresql.org; Fri, 01 Dec 2023 01:42:49 +0000 Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id C0F015C010A; Thu, 30 Nov 2023 20:42:46 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Thu, 30 Nov 2023 20:42:46 -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:sender :subject:subject:to:to; s=fm1; t=1701394966; x=1701481366; bh=5I js0/i7Pdpf/6M5yHgfw/G0HhRXbmvY2CLMM4GJ7kI=; b=p7WcVBe1bOGHX/iqPP DlKWFP+uurj26zAgIDY/jxipIJ2hrjl5mNnHuwnt67f0IVm+7bdlsNdi7pQMIUDW x2rprg+m/JKNfHi3L7ZAjnq/uOHspTQzc0sbZRfyK6XTWBTUT0olCTba26odLkQA TxpjxTMZ3lvH8tq0kCREiCnq0zKofi8Ngjw6QjHltQVR3OINL3TTh1Ji0e9WyZVl crIlW9ZGE22d9FTnUnjs+lATv7XW3pmjyFK13I1MGloOOBeZ2xWVchXcK2vVUHyy iMliEmvA2U4J8OUl4BW3yxptv3x/Rd6lrBSRE4YrgafTMBB4wTyq8P0muaRxk1fE p03w== 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:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1701394966; x=1701481366; bh=5Ijs0/i7Pdpf/ 6M5yHgfw/G0HhRXbmvY2CLMM4GJ7kI=; b=GMI4PiPVTQsvzySTx0Gh3ddLxDSi5 imlS8TOUGbGDH7g3wdBT2OSAHroIoCTZipBCK2/K6ZvhuKGKov9QNEvqmToLFgIE cOwvf67IZkIt5Th5n9ZgUlplgkXs1BnWNgdhIfkkQOOUddHtu0KzUVpf4XxAGGJS GBPCw+ZXGRGUaI43I/XgGFr5JloQz+a4sWONCZZqHJaCSXw7+Ki2XoMvT/ZmqslZ j0399sHYmjkPG2zF4kOs1xCXf/SqbwU8ZFMSMHhoYb6tONVMZ9nArd+bm+aq9w3B 2zu0OjnCeb7+8RoP3QWyr9hsdsIYSzueLq8JDQhhLHdIOro/TMm8MCQdA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvkedrudeikedgfeejucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughr vghsucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrf grthhtvghrnhepvdfffeevhfetveffgeeiteefhfdtvdffjeevhfeuteegleduheetvedu ieettddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh eprghnughrvghssegrnhgrrhgriigvlhdruggv X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 30 Nov 2023 20:42:45 -0500 (EST) Date: Thu, 30 Nov 2023 17:42:44 -0800 From: Andres Freund To: Heikki Linnakangas Cc: Tristan Partin , pgsql-hackers , Thomas Munro Subject: Re: Refactoring backend fork+exec code Message-ID: <20231201014244.zdngaok5wb74blms@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> <3df4b075-fb15-4e35-8981-10ed29aef208@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3df4b075-fb15-4e35-8981-10ed29aef208@iki.fi> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2023-12-01 01:36:13 +0200, Heikki Linnakangas wrote: > On 30/11/2023 22:26, Andres Freund wrote: > > On 2023-11-30 01:36:25 +0200, Heikki Linnakangas wrote: > > > From a96b6e92fdeaa947bf32774c425419b8f987b8e2 Mon Sep 17 00:00:00 2001 > > > From: Heikki Linnakangas > > > Date: Thu, 30 Nov 2023 00:01:25 +0200 > > > Subject: [PATCH v3 1/7] Refactor CreateSharedMemoryAndSemaphores > > > > > > For clarity, have separate functions for *creating* the shared memory > > > and semaphores at postmaster or single-user backend startup, and > > > for *attaching* to existing shared memory structures in EXEC_BACKEND > > > case. CreateSharedMemoryAndSemaphores() is now called only at > > > postmaster startup, and a new AttachSharedMemoryStructs() function is > > > called at backend startup in EXEC_BACKEND mode. > > > > I assume CreateSharedMemoryAndSemaphores() is still called during crash > > restart? > > Yes. > > > I wonder if it shouldn't split three ways: > > 1) create > > 2) initialize > > 3) attach > > Why? What would be the difference between create and initialize phases? Mainly because I somehow mis-remembered how we deal with the shared memory allocation when crashing. I somehow had remembered that we reused the same allocation across restarts, but reinitialized it from scratch. There's a kernel of truth to that, because we can end up re-attaching to an existing sysv shared memory segment. But not more. Perhaps I was confusing things with the listen sockets? Andres