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%40ppiwoigzz6v4
