Horton

Re: failed NUMA pages inquiry status: Operation not permitted

Tomas Vondra <tomas@vondra.me>

View thread
From: Tomas Vondra <tomas@vondra.me>
To: Christoph Berg <myon@debian.org>
Cc: Jakub Wartak <jakub.wartak@enterprisedb.com>, pgsql-hackers@lists.postgresql.org
Date: 2025-12-11T12:46:54Z
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 →

  1. Handle EPERM in pg_numa_init

  2. Add CHECK_FOR_INTERRUPTS into pg_numa_query_pages

  3. Silence valgrind about pg_numa_touch_mem_if_required

  4. Limit the size of numa_move_pages requests

  5. Introduce pg_shmem_allocations_numa view


On 12/11/25 13:29, Christoph Berg wrote:
> Re: Tomas Vondra
>>>> So I'm leaning to adjust pg_numa_init() to also check EPERM, per the
>>>> attached patch. It still calls numa_available(), so that we don't
>>>> silently miss future libnuma changes.
>>>>
>>>> Can you check this makes it work inside the docker container?
>>>
>>> Yes your patch works. (Sorry I meant to test earlier, but RL...)
>>
>> Thanks. I've pushed the fix (and backpatched to 18).
> 
> It looks like we are not done here yet :(
> 
> postgresql-18 is failing here intermittently with this diff:
> 
> 12:20:24 --- /build/reproducible-path/postgresql-18-18.1/src/test/regress/expected/numa.out	2025-11-10 21:52:06.000000000 +0000
> 12:20:24 +++ /build/reproducible-path/postgresql-18-18.1/build/src/test/regress/results/numa.out	2025-12-11 11:20:22.618989603 +0000
> 12:20:24 @@ -6,8 +6,4 @@
> 12:20:24  -- switch to superuser
> 12:20:24  \c -
> 12:20:24  SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
> 12:20:24 - ok
> 12:20:24 -----
> 12:20:24 - t
> 12:20:24 -(1 row)
> 12:20:24 -
> 12:20:24 +ERROR:  invalid NUMA node id outside of allowed range [0, 0]: -2
> 
> That's REL_18_STABLE @ 580b5c, with the Debian packaging on top.
> 
> I've seen it on unstable/amd64, unstable/arm64, and Ubuntu
> questing/amd64, where libnuma should take care of this itself, without
> the extra patch in PG. There was another case on bullseye/amd64 which
> has the old libnuma.
> 
> It's been frequent enough so it killed 4 out of the 10 builds
> currently visible on
> https://jengus.postgresql.org/job/postgresql-18-binaries-snapshot/.
> (Though to be fair, only one distribution/arch combination was failing
> for each of them.)
> 
> There is also one instance of it in
> https://jengus.postgresql.org/job/postgresql-19-binaries-snapshot/
> 
> I currently have no idea what's happening.
> 

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?

regards

-- 
Tomas Vondra