| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Christoph Berg <myon(at)debian(dot)org> |
| Cc: | 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-28 15:14:43 |
| Message-ID: | a05ca971-a8ea-422f-85cd-b5edc46c5a9a@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 10/16/25 17:19, Christoph Berg wrote:
>> So maybe all that's needed is a get_mempolicy() call in
>> pg_numa_available() ?
>
> ...
>
> So maybe PG should implement numa_available itself like that. (Or
> accept the output difference so the regression tests are passing.)
>
I'm not sure which of those options is better. I'm a bit worried just
accepting the alternative output would hide some failures in the future
(although it's a low risk).
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?
regards
--
Tomas Vondra
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Handle-EPERM-in-pg_numa_init.patch | text/x-patch | 873 bytes |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2025-10-28 15:20:50 | Re: failed NUMA pages inquiry status: Operation not permitted |
| Previous Message | Peter Eisentraut | 2025-10-28 09:17:07 | pgsql: Check that index can return in get_actual_variable_range() |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jacob Champion | 2025-10-28 15:18:50 | Re: Channel binding for post-quantum cryptography |
| Previous Message | Robert Haas | 2025-10-28 14:57:26 | Re: Making pg_rewind faster |