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-12-13T17:36:07Z

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: Tomas Vondra
> Hmmm, strange. -2 is ENOENT, which should mean this:
> 
>        -ENOENT
>               The page is not present.
> 
> But what does "not present" mean in this context? And why would that be
> only intermittent? Presumably this is still running in Docker, so maybe
> it's another weird consequence of that?

Sorry I forgot to mention that this is now in the normal apt.pg.o
build environment (chroots without any funky permission restrictions).
I have not tried Docker yet.

I think it was not happening before the backport of the Docker fix.
But I have no idea why this should have broken anything, and why it
would only happen like 3% of the time.

Christoph