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 1sCR5I-005duj-GL for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 21:43:49 +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 1sCR5H-00HARB-O9 for pgsql-general@arkaria.postgresql.org; Wed, 29 May 2024 21:43:47 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sCR5H-00HAR2-DO for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 21:43:47 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1sCR5E-001PSN-Gd for pgsql-general@lists.postgresql.org; Wed, 29 May 2024 21:43:46 +0000 Received: from pro.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 44TLhgm01644322; Wed, 29 May 2024 17:43:42 -0400 From: Tom Lane To: =?utf-8?B?Q2hyaXN0aWFuIFNjaHLDtmRlcg==?= cc: Francisco Olarte , "pgsql-general@lists.postgresql.org" , Eric Wong Subject: Re: Memory issues with PostgreSQL 15 In-reply-to: References: Comments: In-reply-to =?utf-8?B?Q2hyaXN0aWFuIFNjaHLDtmRlcg==?= message dated "Tue, 28 May 2024 22:59:13 -0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3331.1717019021.1@sss.pgh.pa.us> Content-Transfer-Encoding: quoted-printable Date: Wed, 29 May 2024 14:43:41 -0700 Message-ID: <3332.1717019021@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk =3D?utf-8?B?Q2hyaXN0aWFuIFNjaHLDtmRlcg=3D=3D?=3D writes: > # ipcs -m > ------ Shared Memory Segments -------- > key shmid owner perms bytes nattch status > 0x04000194 35 postgres 600 56 19 > I am surprised to see this since I would have expected much more shared = memory to be used by the database. Is there anything in the configuration = that prevents the shared memory from being used? SysV shared memory isn't that relevant to Postgres anymore. Most of what we allocate goes into POSIX-style shared memory segments, which are not shown by "ipcs". We do still create one small fixed-size data structure in SysV memory, which is what you're seeing here, for arcane reasons having to do with the lifespan of the shared memory segments being different in those two APIs. >> <2024-05-21 11:34:46 CEST - mailprocessor> ERROR: could not resize >> shared memory segment "/PostgreSQL.2448337832" to 182656 bytes: No >> space left on device This seems to indicate that you're hitting some kernel limit on the amount of POSIX shared memory. Not sure where to look for that. regards, tom lane