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>
In-Reply-To: <ab466cd2-fa21-47e5-812c-a944416ac464@vondra.me>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
Date: Wed, 7 Jan 2026 10:01:48 +0100
Message-ID: 
 <CAKZiRmxiGxA6N0YdtTQiDfd9TByLKtdCnqKWNGZMVTKyHgWw4Q@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/CAKZiRmxiGxA6N0YdtTQiDfd9TByLKtdCnqKWNGZMVTKyHgWw4Q%40mail.gmail.com>
Precedence: bulk

Hi Tomas,

On Tue, Jan 6, 2026 at 4:36=E2=80=AFPM Tomas Vondra <tomas@vondra.me> wrote=
:
[..]
> I've always "known" shared buffers could be swapped out, but I've never r=
ealized it would affect cases like this one.

Same, I'm a little surprised by it, but it makes sense. In my old and
more recent tests I've always reasoned the following way: NUMA (2+
sockets) --> probably a big production system --> huge_pages literally
always enabled to avoid a variety of surprises (locks the region).
Also this kind of reminds me of our previous past discussion about
dividing shm allocations into smaller requests (potentially 4kB shm
regions that are not huge_pages, so in theory swappable) [1].

> I'm not a huge fan of fixing just the tests. Sure, the tests will pass,
> but what's the point of that if you then can't run this on production
> because it also fails (I mean, the pg_shmem_allocations_numa will fail)?

Well, You are probably right.

> I think it's clear we need to tweak this to handle -2 status. And then
> also adjust tests to accept non-deterministic results.

The only question remains is, if we want to expose it to the user or
not? We could

a) silently ignore ENOENT in the back branches so that "size" won't
contain it (well just change pg_get_shmem_allocations_numa()). It is
not part of any NUMA node anyway. Well, maybe we could emit DEBUG1 or
source code comment about such a fact that we think it may be swapped
out.

b) no sure is it a good idea, but in master we could expose it as a
new column "swapped_out_size" (or change the current datatype of
"numa" column from ::integer to something like ::text to allow
outputting numa_node as integer, but also putting node=3D"swapped-out"
too with proper size). Sounds like a new minor feature that would be
able to tell the user that he has swapped out shm, and needs to really
enable huge pages (?)

-J.

[1] - https://www.postgresql.org/message-id/jqg6jd32sw4s6gjkezauer372xrww7x=
nupvrcsqkegh2uhv6vg%40ppiwoigzz6v4