Re: failed NUMA pages inquiry status: Operation not permitted
| От | Tomas Vondra |
|---|---|
| Тема | Re: failed NUMA pages inquiry status: Operation not permitted |
| Дата | |
| Msg-id | 3b18ec96-5a45-4eaa-a98b-000927c9425b@vondra.me обсуждение исходный текст |
| Ответ на | Re: failed NUMA pages inquiry status: Operation not permitted (Tomas Vondra <tomas@vondra.me>) |
| Ответы |
Re: failed NUMA pages inquiry status: Operation not permitted
|
| Список | 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
В списке pgsql-hackers по дате отправления: