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.96) (envelope-from ) id 1vqdWE-00EtwW-07 for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 20:42:35 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vqdWC-00B9m1-2v for pgsql-hackers@arkaria.postgresql.org; Thu, 12 Feb 2026 20:42:33 +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.96) (envelope-from ) id 1vqdWC-00B9lr-1T for pgsql-hackers@lists.postgresql.org; Thu, 12 Feb 2026 20:42:33 +0000 Received: from fout-b8-smtp.messagingengine.com ([202.12.124.151]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1vqdWA-00000000LEL-2GtP for pgsql-hackers@postgresql.org; Thu, 12 Feb 2026 20:42:32 +0000 Received: from phl-compute-03.internal (phl-compute-03.internal [10.202.2.43]) by mailfout.stl.internal (Postfix) with ESMTP id 0159D1D000B9; Thu, 12 Feb 2026 15:42:29 -0500 (EST) Received: from phl-frontend-03 ([10.202.2.162]) by phl-compute-03.internal (MEProxy); Thu, 12 Feb 2026 15:42:30 -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=1770928949; x=1771015349; bh=ovOtd3/kW/ +VCMLTu2XYItlDinFTSn3NFHC/UULD0V4=; b=Os3SrRhd6Uuc0afTqlcaUduhqp Jd3Cii3XbzOH72J0QmezbQsFbs4b3jyJE9Z3U5T4iboaJ096/8lfpzAI33DPdhuw pQS/DfGZoNOe5lW/3wByh9Mqe4qK5hVBYj791y2WjCGkI/5OnM5qkVS1AF2EMq7H wOFmE6u2dFXLu1ZrF7jGCtmRROfAZrJi73fZSrHfSEMImA/JaU7Np3zxdxOzteAI JY3w3GY+0JAmKoCnMdQV1MOewrZbT1Y4jkjLUWSSX1fQr2H6GFlQHQ8cC7mVSqY9 sGsdHUxT0iYdtyH85fF4iulOAStxwXV08VA2ICLNzm80dEbMEYAD0NzYguuw== 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-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1770928949; x=1771015349; bh=ovOtd3/kW/+VCMLTu2XYItlDinFTSn3NFHC /UULD0V4=; b=AUWvST/NubWonRkbWKq0nMFgOGAxIUzENXvmpGK7g/VrF8Xg1c0 TRwZNwa/LbbTv/O0zbmoEEFcnIPBECuXEzMdjCUnqtSGPQUvkZNswn2nBi96uLba 7CrVbcjOHEr7WZrKz/n6ujNB8aSExbwOb9YazINZQLPcFvM7Dpdoc0pdLmXJxfCv d4uwTkJmuJZMaH3Mhvy7wgEmFrxf7yAwrYjTmWevy/qs01C1pVD69io2JXdSG3u8 EJPgiMfGzFAzRNw5dNplUiHh1/s3UbJhC0/XeMH6V5tuB2wlgqcVoTNZUTT78LIE w6sUUwTqLHTpegKae40KmOjLka+O4UdRKFw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefgedrtddtgddvtdeifeeiucetufdoteggodetrf dotffvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfurfetoffkrfgpnffqhgenuceu rghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujf gurhepfffhvfevuffkfhggtggujgesthdtredttddtvdenucfhrhhomheptehnughrvghs ucfhrhgvuhhnugcuoegrnhgurhgvshesrghnrghrrgiivghlrdguvgeqnecuggftrfgrth htvghrnhepvdfffeevhfetveffgeeiteefhfdtvdffjeevhfeuteegleduheetveduieet tddunecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomheprg hnughrvghssegrnhgrrhgriigvlhdruggvpdhnsggprhgtphhtthhopeelpdhmohguvgep shhmthhpohhuthdprhgtphhtthhopehpvghtvghrsegvihhsvghnthhrrghuthdrohhrgh dprhgtphhtthhopeelvghrthhhrghlihhonheisehgmhgrihhlrdgtohhmpdhrtghpthht oheprghshhhuthhoshhhrdgsrghprghtrdhoshhssehgmhgrihhlrdgtohhmpdhrtghpth htoheptghhrghtuhhrvhgvughiphgrlhgrkhduleduudesghhmrghilhdrtghomhdprhgt phhtthhopehrohgsvghrthhmhhgrrghssehgmhgrihhlrdgtohhmpdhrtghpthhtohepth hhohhmrghsrdhmuhhnrhhosehgmhgrihhlrdgtohhmpdhrtghpthhtohephhhlihhnnhgr khgrsehikhhirdhfihdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehpohhsth hgrhgvshhqlhdrohhrghdprhgtphhtthhopehtohhmrghssehvohhnughrrgdrmhgv X-ME-Proxy: Feedback-ID: id4a34324:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 12 Feb 2026 15:42:28 -0500 (EST) Date: Thu, 12 Feb 2026 15:42:27 -0500 From: Andres Freund To: Heikki Linnakangas Cc: Ashutosh Bapat , Tomas Vondra , Peter Eisentraut , Thomas Munro , Dmitry Dolgov <9erthalion6@gmail.com>, pgsql-hackers@postgresql.org, Robert Haas , chaturvedipalak1911@gmail.com Subject: Re: Changing shared_buffers without restart Message-ID: References: <9ac6082a-2e30-4462-a260-1507452aa962@iki.fi> <91265854-b3ba-45c6-aa44-7e8dcdd51470@iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <91265854-b3ba-45c6-aa44-7e8dcdd51470@iki.fi> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi, On 2026-02-10 00:14:23 +0200, Heikki Linnakangas wrote: > Putting this patch aside for a moment, I don't much like our current > interface for defining shared memory structs anyway. The > [SubSystem]ShmemSize() functions feel too detached from the > ShmemInitStruct() calls. Very much agreed. Besides the other weaknesses, it's particularly annoying to use in extensions, because extensions need to chain the shmem init hook. I also really dislike that we support unattributed shared memory allocations. For one they end up interspersing memory from different subsystems, for another the lack of attributability is bad; it sure is weird that one can't see the amount of memory used by the buffer mapping table or the lock table. > I feel that it'd be good to have a single definition of each shmem struct, > and derive all the other things from there. > > Attached is a proof-of-concept of what I have in mind. Don't look too > closely at how it's implemented, it's very hacky and EXEC_BACKEND mode is > slightly broken, for example. The point is to demonstrate what the callers > would look like. I converted only a few subsystems to use the new API, the > rest still use ShmemInitStruct() and ShmemInitHash(). > > With this, initialization of a subsystem that defines a shared memory area > looks like this: > > -------------- > > /* This struct lives in shared memory */ > typedef struct > { > int field; > } FoobarSharedCtlData; > > static void FoobarShmemInit(void *arg); > > /* Descriptor for the shared memory area */ > ShmemStructDesc FoobarShmemDesc = { > .name = "Foobar subsystem", > .size = sizeof(FoobarSharedCtlData), > .init_fn = FoobarShmemInit, > }; I wonder if the size determination should be a callback too. That way extensions wouldn't need to bother with shmem_request_hook, as introduced in commit 4f2400cb3f1 Author: Robert Haas Date: 2022-05-13 09:31:06 -0400 Add a new shmem_request_hook hook. Currently, preloaded libraries are expected to request additional shared memory and LWLocks in _PG_init(). However, it is not unusal for such requests to depend on MaxBackends, which won't be initialized at that time. Such requests could also depend on GUCs that other modules might change. This introduces a new hook where modules can safely use MaxBackends and GUCs to request additional shared memory and LWLocks. ... And it'd allow us to make the ShmemStructDesc variables const. Eventually I'd really like to not have multiple lists of core subsystems (e.g. currently in CalculateShmemSize(), BaseInit() & InitPostgres(), each top-level sigsetjmp() block, ...) but drive it all through one table. This seems like a nice step towards that. > The ShmemStructDesc provides room for extending the facility in the future. > For example, you could specify alignment there, or an additional "attach" > callback when you need to do more per-backend initialization in EXEC_BACKEND > mode. And with the resizeable shared memory, a max size. And perhaps information about how to deal with NUMAn (e.g. interleave the proc array, but use more complicated behaviour for buffer blocks) and whether to use huge pages (it's not clear it's a win for e.g. pgproc). > Thoughts? There's stuff to quibble with in the details (being a POC), but I think as a whole this would be quite an improvement. Greetings, Andres Freund