Hi Jakub,
On Tue, Feb 10, 2026 at 8:07 PM Jakub Wartak
<[email protected]> wrote:
>
> > I see the bug. Fixed in the attached diff. Please apply it on top of
> > 20260209 and let me know if it fixes the issue for you. I will include
> > it in the next set of patches.
>
> Yes, it fixes that "bug1", given
> shared_buffers = '32 GB'
> max_shared_buffers = '32 GB'
> max_connections = 1000
> huge_pages = 'on'
>
> without it , it was:
> mmap(NULL, 35399925760, PROT_NONE,
> MAP_SHARED|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = 0x7fad34c00000
> mmap(NULL, 1038090240, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE|MAP_HUGETLB, 4, 0) = 0x7facf6e00000
> ftruncate(4, 2074263552) = -1 EINVAL (Invalid argument)
>
> and with it:
> mmap(NULL, 1038090240, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE|MAP_HUGETLB, 4, 0) = 0x7fbf49a00000
> ftruncate(4, 1038090240) = 0
> mmap(NULL, 34361835520, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE|MAP_HUGETLB, 5, 0) = 0x7fb749800000
> ftruncate(5, 34361835520) = 0
>
> So bug1 should be fixed. However there's something odd afterwards:
>
> postgres=# show huge_pages;
> huge_pages
> ------------
> on
> (1 row)
> postgres=# show huge_pages_status ;
> huge_pages_status
> -------------------
> off
> (1 row)
>
> Crosschecking, shows it is true, no HP ended up being allocated:
> $ grep -A 2 /memfd /proc/775241/smaps # postmaster shows no HP
> usage (so just 4kB pages):
> 7f845b7f1000-7f8c5b7f3000 rw-s 00000000 00:01 28682
> /memfd:buffers (deleted)
> Size: 33554440 kB
> KernelPageSize: 4 kB
> --
> 7f8c5b7f3000-7f8c9941f000 rw-s 00000000 00:01 28680
> /memfd:main (deleted)
> Size: 1011888 kB
> KernelPageSize: 4 kB
>
> strace shows silent failure on startup:
> [pid 775320] mmap(NULL, 35399925760, PROT_NONE,
> MAP_SHARED|MAP_ANONYMOUS|MAP_HUGETLB, -1, 0) = -1 ENOMEM (Cannot
> allocate memory)
> [pid 775320] memfd_create("main", 0) = 4
> [pid 775320] mmap(NULL, 1036173312, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE, 4, 0) = 0x7fc3faff3000
> [pid 775320] ftruncate(4, 1036173312) = 0
> [pid 775320] memfd_create("buffers", 0) = 5
> [pid 775320] mmap(NULL, 34359746560, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE, 5, 0) = 0x7fbbfaff1000
> [pid 775320] ftruncate(5, 34359746560) = 0
>
> and further tracking nailed it down to bug2 / silent failure in
> CreateSharedMemoryAndSemaphores()->PrepareHugePages()
PrepareHugePages() seems like a kludge but I haven't yet gotten time
to do something about it.
>
> That must be some logic error there in the patch, because if I have
> huge_pages=on I want it to fail to start instead of silenty fallback
> to off in huge_pages_status.
>
> And this shows another problem with calculating
> shared_memory_size_in_huge_pages - it's wrong right now I think [bug3]. I have
> used postgres -C shared_memory_size_in_huge_pages and have put this value in
> the
> proper sysctl. It told me to use 16879 (which gives *2MB huge page size =
> 33758MBs = 35397828608 bytes, but mmap() wanted less 34359746560 and that's
> ~989MB difference and still it failed)
>
> OK, sure, I'll throw some more huge pages huge pages (17879) instead but then
> it still it cries with bug4 with even more strange another error:
> 2026-02-10 15:05:45.897 CET [775386] DEBUG: reserving space: probe
> mmap(35399925760) with MAP_HUGETLB
> 2026-02-10 15:05:45.897 CET [775386] DEBUG: segment[main]: mmap(1038090240)
> 2026-02-10 15:05:46.142 CET [775386] DEBUG: segment[buffers]:
> mmap(34361835520)
> 2026-02-10 15:05:46.388 CET [775386] FATAL: segment[buffers]: could
> not allocate space for anonymous file: No space left on device
>
> so this time it was
> [pid 775426] memfd_create("main", MFD_HUGETLB) = 4
> [pid 775426] mmap(NULL, 1038090240, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE|MAP_HUGETLB, 4, 0) = 0x7f8b6b200000
> [pid 775426] ftruncate(4, 1038090240) = 0
> [pid 775426] fallocate(4, 0, 0, 1038090240) = 0
> [pid 775426] memfd_create("buffers", MFD_HUGETLB) = 5
> [pid 775426] mmap(NULL, 34361835520, PROT_NONE,
> MAP_SHARED|MAP_NORESERVE|MAP_HUGETLB, 5, 0) = 0x7f836b000000
> [pid 775426] ftruncate(5, 34361835520) = 0
> [pid 775426] fallocate(5, 0, 0, 34361835520) = -1 ENOSPC (No space
> left on device)
>
> 34361835520+1038090240 = 35399925760 bytes total = 16880, but I had
> more than HPs free:
>
> /sys/devices/system/node/node0/hugepages/hugepages-2048kB/free_hugepages:4750
>
> /sys/devices/system/node/node1/hugepages/hugepages-2048kB/free_hugepages:4750
>
> /sys/devices/system/node/node2/hugepages/hugepages-2048kB/free_hugepages:4750
>
> /sys/devices/system/node/node3/hugepages/hugepages-2048kB/free_hugepages:4750
>
> Run out of time to track down those HP bugs, just letting You know.
Thanks a lot for all your tests. I will come around to fixing HP bugs
once I have tackled the high level items mentioned in [1] and shared
memory management rewrite that Heikki is suggesting. May I request you
to keep these tests with you till then. Or if you could investigate
these bugs and provide patches containing fixes, that will help as
well. But it may not be as easy as the bug 1 fix.
[1]
https://www.postgresql.org/message-id/CAExHW5s8s=UhjqNa_Tz1PFCRLzt3=5nvd5vd1wfdkwmqcmf...@mail.gmail.com
--
Best Wishes,
Ashutosh Bapat
