Re: pgsql: Introduce pg_shmem_allocations_numa view
Tomas Vondra <tomas@vondra.me>
From: Tomas Vondra <tomas@vondra.me>
To: Christoph Berg <myon@debian.org>
Cc: Andres Freund <andres@anarazel.de>,
Tomas Vondra <tomas.vondra@postgresql.org>,
pgsql-hackers@lists.postgresql.org
Date: 2025-06-23T21:47:00Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Handle EPERM in pg_numa_init
- 599336c64fc9 19 (unreleased) landed
- 482e98ac4302 18.2 landed
-
Add CHECK_FOR_INTERRUPTS into pg_numa_query_pages
- 54ac4944c36f 18.0 landed
- bf1119d74a79 19 (unreleased) landed
-
Silence valgrind about pg_numa_touch_mem_if_required
- 14e52227e578 18.0 landed
- 81f287dc923f 19 (unreleased) landed
-
Limit the size of numa_move_pages requests
- 45879f48f140 18.0 landed
- 7fe2f67c7c9f 19 (unreleased) landed
-
Introduce pg_shmem_allocations_numa view
- 8cc139bec34a 18.0 cited
On 6/23/25 23:25, Christoph Berg wrote: > Re: Tomas Vondra >> True. If it fails on first call, but succeeds on the other, then the >> problem is likely somewhere else. But also on the second call we won't >> do the memory touching. Can you try setting firstNumaTouch=false, so >> that we do this on every call? > > firstNumaTouch=false, it still fails on the first call. > > I assume you meant actually keeping firstNumaTouch=true - but it still > fails on the first call. > No, I meant firstNumaTouch=false, so that the touching happens on every call. I was wondering if that makes all calls fail. > The memory touching is done for the first call in each backend, but > reconnecting doesn't reset it, I have to restart PG. > I don't follow. Why wouldn't reconnecting reset it? >> At the beginning you mentioned this is happening on i386, armel and >> armhf - are all those in qemu? I've tried on my rpi5 (with 32-bit user >> space), and there everything seems to work fine. But that's aarch64 >> kernel, just the user space if 32-bit. > > I'm testing on i386 in a chroot on a amd64 kernel. (same for x32) > armel and armhf are also 32-bit chroots on a arm64 host. > > https://buildd.debian.org/status/package.php?p=postgresql-18&suite=experimental > > Maybe this is a kernel bug. > Or maybe the 32-bit chroot on 64-bit host matters and confuses some calculation. -- Tomas Vondra