pgsql: Handle ENOENT status when querying NUMA node

Handle ENOENT status when querying NUMA node

We've assumed that touching the memory is sufficient for a page to be
located on one of the NUMA nodes. But a page may be moved to a swap
after we touch it, due to memory pressure.

We touch the memory before querying the status, but there is no
guarantee it won't be moved to the swap in the meantime. The touching
happens only on the first call, so later calls are more likely to be
affected. And the batching increases the window too.

It's up to the kernel if/when pages get moved to swap. We have to accept
ENOENT (-2) as a valid result, and handle it without failing. This patch
simply treats it as an unknown node, and returns NULL in the two
affected views (pg_shmem_allocations_numa and pg_buffercache_numa).

Hugepages cannot be swapped out, so this affects only regular pages.

Reported by Christoph Berg, investigation and fix by me. Backpatch to
18, where the two views were introduced.

Reported-by: Christoph Berg <myon(at)debian(dot)org>
Discussion: 18
Backpatch-through: https://postgr.es/m/aTq5Gt_n-oS_QSpL@msg.df7cb.de

Branch
------
REL_18_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/9796c4f5607be5807f2d2ba9bca1bc87af198db3

Modified Files
--------------
contrib/pg_buffercache/pg_buffercache_pages.c | 12 ++++++++--
src/backend/storage/ipc/shmem.c | 32 +++++++++++++++++++++------
2 files changed, 35 insertions(+), 9 deletions(-)