Re: Better shared data structure management and resizable shared data structures

From: Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>
To: Matthias van de Meent <boekewurm+postgres(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, Robert Haas <robertmhaas(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, chaturvedipalak1911(at)gmail(dot)com
Subject: Re: Better shared data structure management and resizable shared data structures
Date: 2026-04-05 14:16:51
Message-ID: CAExHW5sdRv_BEmskRafZN26eVcR8qoLRDp0bJR=znquhigZUNQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Apr 5, 2026 at 4:50 PM Ashutosh Bapat
<ashutosh(dot)bapat(dot)oss(at)gmail(dot)com> 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 = 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 = 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 <= sum(allocated_size) from pg_shmem_allocations; usually
sum(allocated_size) - RssShmem ~= 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 ~= 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.

--
Best Wishes,
Ashutosh Bapat

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2026-04-05 14:28:53 Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements
Previous Message Álvaro Herrera 2026-04-05 14:09:57 Re: PG 19 release notes and authors