public inbox for [email protected]  

help / color / mirror / Atom feed

From: Jakub Wartak <[email protected]>
To: Tomas Vondra <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: [email protected]
Subject: Re: failed NUMA pages inquiry status: Operation not permitted
Date: Wed, 7 Jan 2026 10:01:48 +0100
Message-ID: <CAKZiRmxiGxA6N0YdtTQiDfd9TByLKtdCnqKWNGZMVTKyHgWw4Q@mail.gmail.com> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<CAKZiRmwV_O73DdSosD-k62kS2wWPc3C8mRZY8j9ozfOu5OLLjg@mail.gmail.com>
	<[email protected]>

Hi Tomas,

On Tue, Jan 6, 2026 at 4:36 PM Tomas Vondra <[email protected]> wrote:
[..]
> I've always "known" shared buffers could be swapped out, but I've never realized 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="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/jqg6jd32sw4s6gjkezauer372xrww7xnupvrcsqkegh2uhv6vg%40ppiwoigzz...

view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected]
  Subject: Re: failed NUMA pages inquiry status: Operation not permitted
  In-Reply-To: <CAKZiRmxiGxA6N0YdtTQiDfd9TByLKtdCnqKWNGZMVTKyHgWw4Q@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox