MIME-Version: 1.0
References: <aRcmK8Bpi77yKbq1@msg.df7cb.de>
 <54329add-59b6-4c08-96f0-a025a7804174@vondra.me>
 <aTq5Gt_n-oS_QSpL@msg.df7cb.de>
 <4ff9578d-1de2-45c1-98c4-29caf99334ff@vondra.me>
 <aUFbrmKrYPBuTZ1c@msg.df7cb.de> <aUFxRjXb7dYj1e8P@msg.df7cb.de>
 <183fe9ab-6010-4cca-b648-1deca332ce2a@vondra.me>
 <aUGc5qh977Y4r_jP@msg.df7cb.de>
 <f1af27db-4e59-4c6b-9d8c-6f667186563a@vondra.me>
 <b93d876b-67c1-4f0e-b0c5-a4296f09f5b5@vondra.me>
 <aVw7Zg9QngFiDOhr@msg.df7cb.de>
 <CAKZiRmwV_O73DdSosD-k62kS2wWPc3C8mRZY8j9ozfOu5OLLjg@mail.gmail.com>
 <ab466cd2-fa21-47e5-812c-a944416ac464@vondra.me>
 <CAKZiRmxiGxA6N0YdtTQiDfd9TByLKtdCnqKWNGZMVTKyHgWw4Q@mail.gmail.com>
 <e13418e8-0596-4955-868d-5376bdb0496f@vondra.me>
In-Reply-To: <e13418e8-0596-4955-868d-5376bdb0496f@vondra.me>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
Date: Mon, 19 Jan 2026 12:47:19 +0100
Message-ID: 
 <CAKZiRmxo-umL9889gD=Z2SZBG4y64qL_PrTmeimcykqDGwdNBQ@mail.gmail.com>
Subject: Re: failed NUMA pages inquiry status: Operation not permitted
To: Tomas Vondra <tomas@vondra.me>
Cc: Christoph Berg <myon@debian.org>, pgsql-hackers@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKZiRmxo-umL9889gD%3DZ2SZBG4y64qL_PrTmeimcykqDGwdNBQ%40mail.gmail.com>
Precedence: bulk

On Fri, Jan 16, 2026 at 10:29=E2=80=AFPM Tomas Vondra <tomas@vondra.me> wro=
te:
>
> 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".

Right, OK, so I've reproduced this without patch (as You have stated, just =
cause
shared_buffers to swap out, in my case it was simple stress-ng -m 16 --vm-b=
ytes
SOME_HIGH_VALUE).

It gets ERROR pretty fast: select numa_node, sum(size) from
pg_shmem_allocations_numa group by numa_node;
    numa_node |     sum
    -----------+-------------
            0 | 24062603264
    (1 row)
and then after pretty soon:
    ERROR:  invalid NUMA node id outside of allowed range [0, 0]: -2

but with patch it (which by the way looks good to me), it does not,
instead I get:

 numa_node |     sum
-----------+-------------
           | 10821046272
         0 | 13241556992

-J.