Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Subject: BUG #19719: BUG: huge_pages=on shared memory reattached without
 FILE_MAP_LARGE_PAGES on Windows
To: pgsql-bugs@lists.postgresql.org
From: PG Bug reporting form <noreply@postgresql.org>
Cc: s-mitsufuji@nec.com
Reply-To: s-mitsufuji@nec.com, pgsql-bugs@lists.postgresql.org
Date: Fri, 25 Sep 2026 04:39:16 +0000
Message-ID: <19719-9eea21ac8841c776@postgresql.org>
Auto-Submitted: auto-generated
Archived-At: 
 <https://www.postgresql.org/message-id/19719-9eea21ac8841c776%40postgresql.org>
Precedence: bulk

The following bug has been logged on the website:

Bug reference:      19719
Logged by:          Satoshi Mitsufuji
Email address:      s-mitsufuji@nec.com
PostgreSQL version: 18.6
Operating system:   Windows 11
Description:       =20

PostgreSQL version: 18.6 (also affects master and any branch since
large-page support for Windows shared memory was introduced)
OS: Windows 10/11 x86_64, msvc build
huge_pages =3D on

Description
-----------
On Windows, when huge_pages=3Don, PGSharedMemoryCreate() (win32_shmem.c)
correctly creates the shared memory section with SEC_LARGE_PAGES and
maps the postmaster's own view with FILE_MAP_LARGE_PAGES:

    if ((flProtect & SEC_LARGE_PAGES) !=3D 0)
        desiredAccess |=3D FILE_MAP_LARGE_PAGES;
    memAddress =3D MapViewOfFileEx(hmap2, desiredAccess, 0, 0, 0, NULL);

However, every other backend process re-attaches to the same section
via PGSharedMemoryReAttach(), which calls MapViewOfFileEx() with only
FILE_MAP_READ | FILE_MAP_WRITE -- FILE_MAP_LARGE_PAGES is never
requested there. As a result, only the postmaster's own view of shared
memory is backed by large pages; every backend, walsender, autovacuum
worker, etc. maps the same physical section as ordinary 4KB pages.

Because Windows requires FILE_MAP_LARGE_PAGES on MapViewOfFileEx when
the underlying section was created with SEC_LARGE_PAGES (mirroring the
requirement added for CreateFileMapping in commit fdd8937c, see also
bug #17448), this looks like an oversight in that same fix: the
postmaster side was updated, but PGSharedMemoryReAttach() was not.

Evidence
--------
Using Sysinternals VMMap on the shared memory VA range in both the
postmaster and a backend process (huge_pages=3Don, shared_buffers=3D256MB,
segment size 292,864 KB):

  Postmaster view of the segment:
    Total WS  : 292,864 K (100% of the segment, resident immediately)
    Locked    : 292,864 K
    Process Page Table size: ~244-276 K

  Backend view of the *same* segment, before fix:
    Total WS  : 1,668 K  (only touched pages faulted in)
    Locked    : (column not present -- not large-page backed)
    Process Page Table size: ~840 K  (comparable to a plain
                              huge_pages=3Doff backend, ~816-840 K)

The backend's page table consumption and lazily-faulted working set
are indistinguishable from a huge_pages=3Doff run, indicating the
backend is using standard 4KB PTEs for this mapping despite
huge_pages=3Don and despite the section itself being backed by large
pages.

RAMMap's "Large Page" counter does not reflect this at all (stays at
0 K in both configurations), which is presumably why this has not
been noticed via that tool; VMMap's per-VAD Locked/WS accounting is
what exposes it.

Proposed fix
------------
Request FILE_MAP_LARGE_PAGES in PGSharedMemoryReAttach() as well,
falling back to a plain mapping if the section was not created with
SEC_LARGE_PAGES (huge_pages=3Doff, or huge_pages=3Dtry that fell back to
normal pages):

--- win32_shmem_originalg.c
+++ win32_shmem_modified_20260922.c
@@ -440,7 +440,17 @@
        if (VirtualFree(UsedShmemSegAddr, 0, MEM_RELEASE) =3D=3D 0)
                elog(FATAL, "failed to release reserved memory region
(addr=3D%p): error code %lu",
                         UsedShmemSegAddr, GetLastError());
=20
+#ifdef FILE_MAP_LARGE_PAGES
+       /*
+        * Try to reattach with FILE_MAP_LARGE_PAGES first. This will fail
with
+        * ERROR_INVALID_PARAMETER if the segment was not created with
+        * SEC_LARGE_PAGES (i.e. huge_pages was off, or fell back to normal
+        * pages under huge_pages=3Dtry). In that case, retry without the
flag.
+        */
+       hdr =3D (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID,
FILE_MAP_READ | FILE_MAP_WRITE | FILE_MAP_LARGE_PAGES, 0, 0, 0,
UsedShmemSegAddr);
+       if (!hdr)
+               hdr =3D (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID,
FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0, UsedShmemSegAddr);
+#else
        hdr =3D (PGShmemHeader *) MapViewOfFileEx(UsedShmemSegID,
FILE_MAP_READ | FILE_MAP_WRITE, 0, 0, 0, UsedShmemSegAddr);
+#endif
        if (!hdr)
                elog(FATAL, "could not reattach to shared memory (key=3D%p,
addr=3D%p): error code %lu",
                         UsedShmemSegID, UsedShmemSegAddr, GetLastError());

I've tested this patch with both huge_pages=3Don and huge_pages=3Doff:

  - huge_pages=3Doff: server starts normally. The first
    MapViewOfFileEx() attempt (with FILE_MAP_LARGE_PAGES) fails as
    expected since the section has no SEC_LARGE_PAGES, and the
    fallback call succeeds -- no FATAL errors, no crash loop.

  - huge_pages=3Don: backends now show Total WS =3D=3D segment size and
    Locked =3D=3D segment size for the shared memory VAD in VMMap,
    matching the postmaster, instead of the partial/non-locked view
    seen before the fix.