Re: failed NUMA pages inquiry status: Operation not permitted
Christoph Berg <myon@debian.org>
From: Christoph Berg <myon@debian.org>
To: Tomas Vondra <tomas@vondra.me>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-10-16T15:06:23Z
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
Re: To Tomas Vondra > It's the very same kernel, just different docker containers on the > same system. I did not investigate yet where the problem is coming > from, different libnuma versions seemed like the best bet. numactl shows the problem already: Host system: $ numactl --show policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 cpubind: 0 nodebind: 0 membind: 0 preferred: debian:trixie-slim container: $ numactl --show physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 No NUMA support available on this system. debian:bookworm-slim container: $ numactl --show get_mempolicy: Operation not permitted get_mempolicy: Operation not permitted get_mempolicy: Operation not permitted get_mempolicy: Operation not permitted policy: default preferred node: current physcpubind: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 cpubind: 0 nodebind: 0 membind: 0 preferred: Running with sudo does not change the result. So maybe all that's needed is a get_mempolicy() call in pg_numa_available() ? Christoph