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 1pJNNJ-0004SY-7x for pgsql-bugs@arkaria.postgresql.org; Sat, 21 Jan 2023 23:34:17 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pJNMJ-0000Bn-S3 for pgsql-bugs@arkaria.postgresql.org; Sat, 21 Jan 2023 23:33:15 +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 1pJNMJ-0000Be-KC for pgsql-bugs@lists.postgresql.org; Sat, 21 Jan 2023 23:33:15 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by makus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pJNMC-0008Cn-Sc for pgsql-bugs@lists.postgresql.org; Sat, 21 Jan 2023 23:33:14 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 30LNX3D61113362; Sat, 21 Jan 2023 18:33:03 -0500 From: Tom Lane To: Andres Freund cc: Tomas Vondra , david_sisson@dell.com, pgsql-bugs@lists.postgresql.org Subject: Re: BUG #17757: Not honoring huge_pages setting during initdb causes DB crash in Kubernetes In-reply-to: <20230121232922.juo7t3fhaso7qh3s@awork3.anarazel.de> References: <17757-dbdfc1f1c954a6db@postgresql.org> <4ce40288-5b88-f9fb-ea11-fc932c61472b@enterprisedb.com> <20230121232922.juo7t3fhaso7qh3s@awork3.anarazel.de> Comments: In-reply-to Andres Freund message dated "Sat, 21 Jan 2023 15:29:22 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1113360.1674343983.1@sss.pgh.pa.us> Date: Sat, 21 Jan 2023 18:33:03 -0500 Message-ID: <1113361.1674343983@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Andres Freund writes: > On 2023-01-22 00:10:29 +0100, Tomas Vondra wrote: >> I doubt we want to just go straight to changing the default value for >> everyone. IMHO if the "try" logic is somehow broken, we should fix the >> try logic, not mess with the defaults. > Agreed. But we could disable huge pages explicitly inside initdb - there's > really no point in using it there... One of the things initdb is trying to do is establish a set of values that is known to allow the server to start. Not using the same settings that the server is expected to use would break that idea completely. regards, tom lane