| From: | Tomas Vondra <tomas(at)vondra(dot)me> |
|---|---|
| To: | Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com> |
| Cc: | Christoph Berg <myon(at)debian(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org |
| Subject: | Re: failed NUMA pages inquiry status: Operation not permitted |
| Date: | 2026-01-16 21:29:47 |
| Message-ID: | e13418e8-0596-4955-868d-5376bdb0496f@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
Hi,
Here's WIP fix for the root cause, i.e. handling status -2 in the two
views querying NUMA node for memory pages:
* pg_shmem_allocations_numa
* pg_buffercache_numa
We can't prevent -2 from happening - the kernel can move arbitrary pages
to swap, we have no control over it. So I think we need to handle -2 as
"unknown" node, instead of failing. The patch simply returns NULL
instead of the node, but in principle we might return some other value
(but IMHO we should not return the raw status, the -2 makes no sense in
our context, it's some internal kernel errno).
The pg_buffercache_numa was not failing, it just returned the -2 status
verbatim. But I modified it to return NULL, for consistency.
AFAIK this will fix the regression tests too - they only check COUNT(*),
not the actual values.
I'm not sure if we need to mention this in the docs. It probably should
mention the column can be NULL, which means "unknown node".
regards
--
Tomas Vondra
| Attachment | Content-Type | Size |
|---|---|---|
| 0001-Handle-ENOENT-status-when-querying-NUMA-node.patch | text/x-patch | 4.8 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Christoph Berg | 2026-01-17 00:31:32 | Re: failed NUMA pages inquiry status: Operation not permitted |
| Previous Message | Peter Eisentraut | 2026-01-16 16:30:10 | pgsql: Fix PL/Python build on MSVC with older Meson |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nathan Bossart | 2026-01-16 21:52:59 | Re: [PATCH] ternary reloption type |
| Previous Message | Alexandra Wang | 2026-01-16 21:26:37 | jsonb subscripting vs SQL/JSON array accessor semantics (SQL:2023) |