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 1w8p8g-000umv-00 for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Apr 2026 00:45:26 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w8p8e-00Emlp-2L for pgsql-hackers@arkaria.postgresql.org; Sat, 04 Apr 2026 00:45:25 +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 1w8p8e-00Emlg-1Q for pgsql-hackers@lists.postgresql.org; Sat, 04 Apr 2026 00:45:24 +0000 Received: from lahtoruutu.iki.fi ([185.185.170.37]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1w8p8c-00000000Rc7-2jKX for pgsql-hackers@postgresql.org; Sat, 04 Apr 2026 00:45:24 +0000 Received: from [10.0.2.15] (unknown [130.41.208.1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange x25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: hlinnaka) by lahtoruutu.iki.fi (Postfix) with ESMTPSA id 4fncM36vHHz49Q1q; Sat, 04 Apr 2026 03:45:19 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1775263520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0t9wxrOcEt9nkzMXVaTSjh8aGgxNbC+/eOaQr2/td78=; b=gqcdJUDNdctdndoezZow6OLXjD/ffZGQBwSj6vvCEqOyFgRK/jLOSsWHqKHhZBoRb3m9oS 1oh3Gwre7oTprkxBcyDHirn0y3SPh5zA9BMmsCWjqokjKxdIXjkB8pQDR6In6rZwngGv7B chhd4qXE5njIkLIhajigO1FKPSNHGYaTJ3dsyIH0Jv+K6zKdG3gtPFUE7nJBKOyJj/Q2Ui cGDWwWkoFmY7pJ1/0VjrXvxn90NprPWXtU7Od8+TIS5ruWlf4g+msG0/pHB69nC61VBJEi Ih1Y9EleVnw3cwwpapQKhjnVLNoL+Kh3YGncZ8qoEkAYEVSk4oCcE6xIQpIZsw== ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1775263520; b=mGDZycXXEAckSBfss6HF2HqT23+rWqrhkucPXfhgUdxNzJ4absz7uqT1+TMWrMKYiibiQO 7+f7DxhK2doGJ4C9hYFnD6qw69vbfqImnHFvJSc3Y5qYBcDHO83GoSCrlcHAnV3iz8FWrj J6NHIILC8sGmqSFfLNb7pBWrFpn8PzS7gMdH5jRWBBY7L1zzjroOmJSnG7IylTR5s7CUo6 O9qa0q3uMayyWNJGw3rLRx3eMPQ8onf5Bc9BOcYXESFwpS8L0/WXqI1igdKU48TbRFNt2n kQUGb01KoCHAD6SX21zNZs3zMF2cfC13TyxNepfykgvM6+etjNtyLiTUU4sanQ== ARC-Authentication-Results: i=1; ORIGINATING; auth=pass smtp.auth=hlinnaka smtp.mailfrom=hlinnaka@iki.fi ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1775263520; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0t9wxrOcEt9nkzMXVaTSjh8aGgxNbC+/eOaQr2/td78=; b=dpa0XEFmHtiqizsRxEARfV0YKsidFN1Se4DlfgkKCUNez4l/rCLdehn48+W9eim0OjYWFx o+Uw5/xHigBT27NID5Y0XLgIVJfMZxe4CE2AmMQHM++m5QlGboVlVGr05kGlTwerts04JF a7z6E5IvDfl+30byuGeuQJ7nMw9RWbKCMfrfo9JcxvQ7ceRRtn7ECf1WUFhwhoNIY6L8Jr OnqvNn7BYeRUGDIiYUzhU2VebxL2EpKZWWk4R/n6EYbnlTnq8xhfOZK7hdeTOoJOyN3FHM rY6cvq15vEKib6W/zwFQ0j8E6WxIarxEZbyDpzTlkXhWcvunJivJBQkluZUWEQ== Message-ID: <7d3ba240-9350-4dfc-bbe1-be6584aee236@iki.fi> Date: Sat, 4 Apr 2026 03:45:18 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Better shared data structure management and resizable shared data structures To: Ashutosh Bapat , Matthias van de Meent Cc: Robert Haas , Andres Freund , pgsql-hackers , chaturvedipalak1911@gmail.com References: <8a6799be-bd42-49fb-8914-856c97bb1977@iki.fi> <113724ab-0028-493f-9605-6e8570f0939f@iki.fi> <791c3f18-f4de-4d84-ac6b-c7ccc074dd38@iki.fi> <9d919bd9-94dd-4bda-8ccf-ebced4178c53@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 03/04/2026 16:12, Ashutosh Bapat wrote: > On Fri, Apr 3, 2026 at 3:40 AM Matthias van de Meent > wrote: >> While I do think it's an improvement over the current APIs, the >> improvement seems to be mostly concentrated in the RequestStruct/Hash >> department, with only marginal improvements in RegisterShmemCallbacks. >> I feel like it's missing the important part: I'd like >> direct-from-_PG_init() ShmemRequestStruct/Hash calls. If >> ShmemRequestStruct/Hash had a size callback as alternative to the size >> field (which would then be called after preload_libraries finishes) >> then that would be sufficient for most shmem allocations, and it'd >> simplify shmem management for most subsystems. >> We'd still need the shmem lifecycle hooks/RegisterShmemCallbacks to >> allow conditionally allocated shmem areas (e.g. those used in aio), >> but I think that, in general, we shouldn't need a separate callback >> function just to get started registering shmem structures. >> >> I also noticed that ShmemCallbacks.%_arg are generally undocumented, >> and I couldn't find any users in core (at the end of the patchset) >> that actually use the argument. Could it be I missed something? None of the current code currently uses it, that's correct. I felt it might become very handy in the future or in extensions, if you wanted to reuse the same function for initializing different shmem areas, for example. It's a pretty common pattern to have an opaque pointer like that in any callbacks. >> I don't understand the use of ShmemStructDesc. They generally/always >> are private to request_fn(), and their fields are used exclusively >> inside the shmem mechanisms, with no reads of its fields that can't >> already be deduced from context. Why do we need that struct >> everywhere? > > My resizable shared memory structure patches use it as a handle to the > structure to be resized. Right. And hash tables and SLRUs use a desc-like object already, so for symmetry it feels natural to have it for plain structs too. I wonder if we should make it optional though, for the common case that you have no intention of doing anything more with the shmem region that you'd need a desc for. I'm thinking you could just pass NULL for the desc pointer: ShmemRequestStruct(NULL, .name = "pg_stat_statements", .size = sizeof(pgssSharedState), .ptr = (void **) &pgss, }; - Heikki