| 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-26 23:32:28 |
| Message-ID: | 3b18ec96-5a45-4eaa-a98b-000927c9425b@vondra.me |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-committers pgsql-hackers |
On 1/16/26 22:29, Tomas Vondra wrote:
> 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".
>
Pushed and backpatched to 18. Hopefully that fixes this.
regards
--
Tomas Vondra
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-01-26 23:33:50 | Re: pgsql: Implement WAIT FOR command |
| Previous Message | Tomas Vondra | 2026-01-26 23:29:16 | pgsql: pgindent fix for 3fccbd94cba |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Heikki Linnakangas | 2026-01-26 23:33:50 | Re: pgsql: Implement WAIT FOR command |
| Previous Message | Andres Freund | 2026-01-26 23:25:44 | Re: unnecessary executor overheads around seqscans |