Re: failed NUMA pages inquiry status: Operation not permitted - Mailing list pgsql-hackers

From Jakub Wartak
Subject Re: failed NUMA pages inquiry status: Operation not permitted
Date
Msg-id CAKZiRmwV_O73DdSosD-k62kS2wWPc3C8mRZY8j9ozfOu5OLLjg@mail.gmail.com
Whole thread Raw
In response to Re: failed NUMA pages inquiry status: Operation not permitted  (Christoph Berg <myon@debian.org>)
Responses Re: failed NUMA pages inquiry status: Operation not permitted
List pgsql-hackers
On Mon, Jan 5, 2026 at 11:30 PM Christoph Berg <myon@debian.org> wrote:
>
> Re: Tomas Vondra
> > I guess the only solution is to accept -2 as a possible value (unknown
> > node). But that makes regression testing harder, because it means the
> > output could change a lot ...

Hi Tomas! That's pretty wild, nice find about that swapping s_b thing!
So just to confirm, that was reproduced outside containers/docker,
right?

> Or just not test that, or do something like
>
> select numa_node = -2 or numa_node between 0 and 1000 from pg_shmem_allocations_numa;

Well, with the huge-pages it should be not swappable, so another idea
would be simply alter first line of src/test/regress/sql/numa.sql and
sql/pg_buffercache_numa.sql just like below:
- SELECT NOT(pg_numa_available()) AS skip_test \gset
+ SELECT (pg_numa_available() is false OR
current_setting('huge_pages_status')::bool is false) as skip_test
\gset

(I'm making assumption that there are buildfarm animals that
huge_pages enabled, no idea how to check that)

-J.



pgsql-hackers by date:

Previous
From: Xuneng Zhou
Date:
Subject: Re: Implement waiting for wal lsn replay: reloaded
Next
From: Fujii Masao
Date:
Subject: Re: [PATCH] Expose checkpoint reason to completion log messages.