Re: Better shared data structure management and resizable shared data structures - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Better shared data structure management and resizable shared data structures
Date
Msg-id CAExHW5sdRv_BEmskRafZN26eVcR8qoLRDp0bJR=znquhigZUNQ@mail.gmail.com
Whole thread
In response to Re: Better shared data structure management and resizable shared data structures  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
List pgsql-hackers
On Sun, Apr 5, 2026 at 4:50 PM Ashutosh Bapat
<ashutosh.bapat.oss@gmail.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



pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: PG 19 release notes and authors
Next
From: Heikki Linnakangas
Date:
Subject: Duplicate RequestNamedLWLocktranche() names and test_lwlock_tranches improvements