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 1pVxWC-0008LY-95 for pgsql-admin@arkaria.postgresql.org; Sat, 25 Feb 2023 16:35:28 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pVxWA-0007ZK-0m for pgsql-admin@arkaria.postgresql.org; Sat, 25 Feb 2023 16:35:26 +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 1pVxW9-0007Z9-M0 for pgsql-admin@lists.postgresql.org; Sat, 25 Feb 2023 16:35:25 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pVxW5-0000JV-6M for pgsql-admin@lists.postgresql.org; Sat, 25 Feb 2023 16:35:24 +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 31PGZHJQ1177970; Sat, 25 Feb 2023 11:35:18 -0500 From: Tom Lane To: Evan Rempel cc: Chris Hoover , pgsql-admin@lists.postgresql.org Subject: Re: New PG14 server won't start with >2GB shared_buffers In-reply-to: <8b47c295-4b16-1a00-32e4-807103816475@uvic.ca> References: <4b583c4a-022f-f452-c0c8-0a932a6ee411@gmail.com> <4a41387e-516e-0782-6110-89c05a99d020@sqlexec.com> <20230225144930.GS9791@aart.rice.edu> <8b47c295-4b16-1a00-32e4-807103816475@uvic.ca> Comments: In-reply-to Evan Rempel message dated "Sat, 25 Feb 2023 07:16:55 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1177968.1677342917.1@sss.pgh.pa.us> Date: Sat, 25 Feb 2023 11:35:17 -0500 Message-ID: <1177969.1677342917@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Evan Rempel writes: > Bear in mind that if you are using systemd to start postgres, then these > user limits may not apply. Yeah, it seems likely that the PG server is being started under more-restrictive limits than what these manual reports suggest. It would be useful to try logging in as the Postgres OS user and manually starting the server -- just do "postgres &" and see what happens. (If it does start, "pg_ctl stop" can be used to shut it down again, or you can manually send SIGTERM to the postmaster process.) I tried to reproduce the problem by intentionally setting "ulimit -v" too small for my PG settings, and I got error messages that were similar but not identical to what Chris reported. (I think the sysv case failed at shmat() not shmget().) So it's probably not ulimit per se that's responsible. But if the server is being started under systemd, then I can entirely believe that systemd has some poorly-documented feature that sets additional limits for daemon processes. I'm still wondering about cgroups, too. regards, tom lane