From: | Christoph Berg <myon(at)debian(dot)org> |
---|---|
To: | Tomas Vondra <tomas(at)vondra(dot)me> |
Cc: | Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: failed NUMA pages inquiry status: Operation not permitted |
Date: | 2025-10-16 14:54:24 |
Message-ID: | aPEHINwaAxsQNAIP@msg.df7cb.de |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers pgsql-hackers |
Re: Tomas Vondra
> It's probably more about the kernel version. What kernels are used by
> these systems?
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.
Same (differing) results on both these systems:
Linux turing 6.16.7+deb14-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.16.7-1 (2025-09-11) x86_64 GNU/Linux
Linux jenkins 6.1.0-39-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.148-1 (2025-08-26) x86_64 GNU/Linux
> Not sure how would that work. It seems this is some sort of permission
> check in numa_move_pages, that's not what pg_numa_available does. Also,
> it may depending on the page queried (e.g. whether it's exclusive or
> shared by multiple processes).
It's probably the lack of some process capability in that environment.
Maybe there is a way to query that, but I don't know much about that
yet.
Christoph
From | Date | Subject | |
---|---|---|---|
Next Message | Christoph Berg | 2025-10-16 15:06:23 | Re: failed NUMA pages inquiry status: Operation not permitted |
Previous Message | Tomas Vondra | 2025-10-16 14:27:47 | Re: failed NUMA pages inquiry status: Operation not permitted |
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2025-10-16 15:01:13 | Re: doc: create table improvements |
Previous Message | Karina Litskevich | 2025-10-16 14:43:23 | Re: pg_stat_statements: faster search by queryid |