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 1w9OHm-001OhO-2A for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2026 14:17:10 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1w9OHl-00390v-0O for pgsql-hackers@arkaria.postgresql.org; Sun, 05 Apr 2026 14:17:09 +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.96) (envelope-from ) id 1w9OHk-00390n-2g for pgsql-hackers@lists.postgresql.org; Sun, 05 Apr 2026 14:17:09 +0000 Received: from mail-wr1-x432.google.com ([2a00:1450:4864:20::432]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.98.2) (envelope-from ) id 1w9OHi-00000000jlY-1xep for pgsql-hackers@postgresql.org; Sun, 05 Apr 2026 14:17:08 +0000 Received: by mail-wr1-x432.google.com with SMTP id ffacd0b85a97d-43cff5dafc3so2878697f8f.1 for ; Sun, 05 Apr 2026 07:17:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1775398624; cv=none; d=google.com; s=arc-20240605; b=Nf5ZqLFsHmrfJmOxPOj79m1SC91cMbkM13HvpDbH2InCyZbaSBOj5aize0qVSa0Rvs 7nEu3RYU0rY5iVnf+WgIClv6mBqZKw6Vh4AqdwJvQVSPI1cZ3XMyKJcDSZ5uf3oPw729 v3mlk0vTalX2ctgCZyhA0pPnPt+4E88wJX5WafrpeEnKRvRwHQsXm4rIL1IqO0aIYIaW aY8yM0SaEIMSW0R542QKDkqW8G14sjJHucjj2Vl3vh4Vn/WlYikpDZST4weMnCp797eU iL4fFY0TnHAOTkRWcd91zxUVZiA1hMRYV/XPCX+O4P+S4HbbDCeHcBx8I3SQvK4MA7pa 5Rbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=tfE0MObqqUj2BKETXIbeuw0j+KI1Ksuu9wKu/c/an1g=; fh=qYwVkKmBs1ScY4IbSySV4ostroVl85ZRgOlDUaRK3Es=; b=hsOxRPKrtSA9UweVDknS5TnUURnIy8cI7Tmbx8D0BqSuWoCdfshHtDJsX2dCkXppDm B1hlsFSOhw4mj3w0IHb12cHHajWMUxKEoHzutxiWkj6RD79cWHvzaUIWPycoOMQ6xI20 i4vju7pS+UOd/fMmvJLLJe60RuA/ahAAVPQlT08VMCjYW2ocj45KaxuDkuWBaFB7YtA6 EzqfZTUa4b9VkW/6CUWujEd/1ZnIY2APF5CJkFeAgw645kuf35TDvwkIyU4YZiNKcTiD tc2hBWhhIfsn+my7a0gzL0+0jO3d6XLYVlTgt/bLw+IpOIZZJLFefcLuY63jJekfHntb hokw==; darn=postgresql.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1775398624; x=1776003424; darn=postgresql.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=tfE0MObqqUj2BKETXIbeuw0j+KI1Ksuu9wKu/c/an1g=; b=hN0wnsO8c6MSM+MIvGN1KqF5TkbeeHMQ1/Ts8WfhAio5WvieReOqFq4Sb2p8p15TGd Y3Nvboy3rh+BU7UvIHM4NnUhz/gK7g2S8mQodK+i9R+MJB0C9vJJSe/rVW4KKwlsaWnx jRPy30/JsbhYzPULLgr6ET3d5w2kuVP8CdMLV5hp+gHkEg6ry4XfDXYXCXQcZBwPvmKw WCZH4uu8GxvGusXhNYC6vLWkzG8Kr93gPE62lDN3zSzKgRaZs4iHd7c4NpYp1w2nE5SM yTkxBNnnYuqvegJNml+B6+kMPWL9xfI1RbmQUgO5aVST7DQVGqXK5TJnhz8JWuCY92UN StZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1775398624; x=1776003424; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=tfE0MObqqUj2BKETXIbeuw0j+KI1Ksuu9wKu/c/an1g=; b=gdQTuLbr1lQOCm3tEXiGTjb5b7XPctKJzMzk5eTd5wAKps+RZHIz2dpBhrIJ/TQjI4 P9QGqk+xM7Veoslbju9sup54vDTVM+Pdjd2DpycZQ3EcZ68KNanRdbGQPK8ql8k+wLnn m8WqN7x1US0ZXjq2Kpx99UiQRrkdfqkOCTjWqGn06ZSHTSR2XC0rePn/XYjOJBLsp8eQ xApmn70NcnCHrfIsfXkU8CVe5vBQzf8CZkcxHKQfDcIDT1mm+EFHiyLZOUhY0mgjc66Q EeTvCT7liLIUJX/ohb3OktkcSQmAPglHy6kbEx3zINmmU/OplhKKlJfyqiuUa0WPasc5 baog== X-Forwarded-Encrypted: i=1; AJvYcCW2hmusKnKyx6UOUQ7zYocFxlEgookoDZh1znd41A5kmSIshrL/ojgSuNFuF6W2fyUXqz3sPDSg3FAtVeSG@postgresql.org X-Gm-Message-State: AOJu0YwwKeXAsGVh1Hn/noiu4IScjTOY5txl1eq0CJMTdvm8g46M2V3H TLfN9xKi4hXxA2Ph40OSnGzPpag5IYNgmMPP9Te5fT1LUiWZ5sSmWTNqSV4EcDeMCnlfxS4epaK 9s4Wvsm+JmlmcLKwRZEVSpOGF6RP4nes= X-Gm-Gg: AeBDiest3a8zmN7t/qBA5et/O/H3EhO/HxcqHEtIaw2U+1pCihLWQUwYvPKds2m4HV7 X936donKawHNsdEVquOJf6a1T0vw2xH9SJbd0qYMc4MNsJ9/7TehoAKKG/dUY5qxlLt8IrdR1c1 kmx1TSYL+QcDPoyMDgZffS+w6OL/OtqbDjOHn4zw6JaudRrGdFkZt4H14oWGcfo3z1aLZ+9kv/Q Zy2GO9II9VbXSdgVxtYQSFkMiXV7WkP9nJ35v1l1Bg7LHEsAsSV6qGdyN0gg76w7S/FOr8O9ay0 ujWdxN4U1Wl9tUD3BE6D87tNg2dB+yczN5HA7tR2SJfLp07C2jEJ X-Received: by 2002:adf:f290:0:b0:43d:30b8:a433 with SMTP id ffacd0b85a97d-43d30b8a49dmr7256954f8f.0.1775398623716; Sun, 05 Apr 2026 07:17:03 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Ashutosh Bapat Date: Sun, 5 Apr 2026 19:46:51 +0530 X-Gm-Features: AQROBzBfXwfymEIoVSWZSCw6cu7IXtWIPdAmwofQRqCZOyKepd9qBXGc_IU_oAU Message-ID: Subject: Re: Better shared data structure management and resizable shared data structures To: Matthias van de Meent Cc: Heikki Linnakangas , Robert Haas , Andres Freund , pgsql-hackers , chaturvedipalak1911@gmail.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On Sun, Apr 5, 2026 at 4:50=E2=80=AFPM Ashutosh Bapat wrote: > > 3. The test fails one one machine because RssShmem is consistently 8MB > higher than the allocated_size in all cases. I guess it is because of > huge page setting. Adding huge_pages =3D off to the test configuration. > I think the test can not rely on huge pages anyway since > allocated_size isn't aligned to huge page size. Turning huge_pages =3D off didn't help. The test actually creates a resizable shared memory structure which is 100s of MBs and adjusts GUCs so that very minimum shared memory is allocated. This way the resizable structure dominates the shared memory segment. Any small variations in RssShmem because of parts of shared memory not accessed by a backend can be ignored. Then it expects that the RssShmem of a backend <=3D sum(allocated_size) from pg_shmem_allocations; usually sum(allocated_size) - RssShmem ~=3D 2MB. That's not accurate but it's the closest I can get to make sure that we do not over allocate memory for resizable shared structures. There is something on https://cirrus-ci.com/task/5501660157444096 which is mapping shared memory worth 10MB, other than the main shared memory segment, consistently in all the backends. Because of that RssShmem - sum(allocated_size) is consistently ~=3D 8MB. I am not able to figure out where that 10MB is coming from. If we could know that, we could either disable the test on that machine or disable that allocation. On all other CFBot VMs, the test is passing, including the platforms where the feature is not supported. --=20 Best Wishes, Ashutosh Bapat