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 1w9Pjy-001PjP-1p for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2026 15:50:22 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9Pjw-003jd0-2v for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2026 15:50:21 +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 1w9Pjw-003jcs-22 for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2026 15:50:21 +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 1w9Pju-00000000hUR-1n3h for pgsql-hackers@postgresql.org; Sun, 05 Apr 2026 15:50:20 +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 4fpcNh3HVTz49Q0Q; Sun, 05 Apr 2026 18:50:12 +0300 (EEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=iki.fi; s=lahtoruutu; t=1775404213; 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=BkttRKcDhObQrRA3zKJNKiOb+jOiCIfwv2ur8IuYapg=; b=Of2zb82ybx6JEyrzLMtfPaA2HtW0YZ87crQzjBBHFwSlqE1Xo6UmMy4JngN7Z0eR1okbca gsCJ7eDqNXY2tYIreL7kTG+y5Ms2kWLPZmWrCHnYmnozr8abEAKqH44rOrF/LoP2/wbp8T LVURclXYuPD8H6aNcNLQkUOucw5jCC47VtpJE1kJPwJk4DSOWWHQbv8daPnBYcsMC7BaAd UzYmzhPgFqFU82YOmP3GWmA4cw1ioKOR7VnzeJqWt58pvexLwjncTbYUBj4/JoPoQHzLiD 08v8IChIoIAziHJmQyT5UljfCm/P0c9mU+BOckkxgIIeTk40UtY6Fpzw+YJ/wQ== ARC-Seal: i=1; a=rsa-sha256; d=iki.fi; s=lahtoruutu; cv=none; t=1775404213; b=XccqJYJ+HgcVZUewqjZzqUMlPSe8Pk7kMjP6v/G21WEIY4BrcekDSiHXNjSXBoiVtQiJlR KnzTj5WRcX8fIbzb/zKFmZQSShYYLbkjmhi13C+euA5BzREwvsSANTfnk3gXtevqN5Htfn cRGRXXbhyRg2w2phbiLsomswwTuG5c9nQEUKoyJ1cAia6RHmyFpcFLCOPz6WBBUcri3JqT YOncBtW++5IgNJQKf/zSkOg6SaKh7/+zHasBbVjlGl7eyS/jxwkXIIDGt0GL1owrAa+f13 X4znddUK6PYVRNmVuQ/rdCrA8YaioZn7MM0v0x3V8ZxgY30eCRxwmDvjp8S4oA== 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=1775404213; 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=BkttRKcDhObQrRA3zKJNKiOb+jOiCIfwv2ur8IuYapg=; b=TLHykd3UMBnAnkwY0/ScgWAuhG5ijlD6ye3cH2b6bdMbR42TQgRr8wMiuMCYPErNjrUUyo j19E7CnMXx6DFQDJWgjA79l0mTQ4A+ke5zSlP48UkXIiLwFFo6Vpxe6I8Ka+5Hb24oJ53v ClyLojhf8G37YbY6W+AujAa9XgA8T257gw0Me47kTsMmjPqHgGc7oqcBjrJLDnb/Usg+WM BAlaE+XYVBu4LTI6ApUYzsx/mcenKaQ2k/FrY77kfOwenuAFRHaA2LsoRxZMbOKIo3pUV4 nR4y4BiDA4iGN2BrNaluctC3HX+/9Lqz2Xx9fDhwixzBIgi4XDP6FaLFuAsv/A== Message-ID: <34d1acd9-0aff-4d59-ada3-a583e1173043@iki.fi> Date: Sun, 5 Apr 2026 18:50:11 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Better shared data structure management and resizable shared data structures To: Matthias van de Meent Cc: Ashutosh Bapat , Robert Haas , Andres Freund , pgsql-hackers , chaturvedipalak1911@gmail.com References: <113724ab-0028-493f-9605-6e8570f0939f@iki.fi> <791c3f18-f4de-4d84-ac6b-c7ccc074dd38@iki.fi> <9d919bd9-94dd-4bda-8ccf-ebced4178c53@iki.fi> <7d3ba240-9350-4dfc-bbe1-be6584aee236@iki.fi> <1c3a07a7-158d-4800-927c-2641c73277d8@iki.fi> Content-Language: en-US From: Heikki Linnakangas In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 05/04/2026 02:17, Matthias van de Meent wrote: >> + pgss->extent = 0; >> + pgss->n_writers = 0; >> + pgss->gc_count = 0; >> + pgss->stats.dealloc = 0; > > Shmem is said to be zero-initialized, should we remove the manual > zero-initialization? Yeah, perhaps. We already had initialization like this in many places, while others relied on the implicit initialization. Some places even do just this: void LogicalDecodingCtlShmemInit(void) { bool found; LogicalDecodingCtl = ShmemInitStruct("Logical decoding control", LogicalDecodingCtlShmemSize(), &found); if (!found) MemSet(LogicalDecodingCtl, 0, LogicalDecodingCtlShmemSize()); } I think there are two directions we could go here: 1. Document that the memory is zeroed, and you can rely on it. Remove silly initializations like that in LogicalDecodingCtlShmemInit(). In other places the explicitly zero-initialization might have documentation value though. 2. Require the init functions to explicitly zero the memory. Document it and add valgrind checks. I'm inclined to go with 1. But in the name of avoiding scope creep, not as part of these patches. - Heikki