Handle EPERM in pg_numa_init
authorTomas Vondra <tomas.vondra@postgresql.org>
Thu, 20 Nov 2025 11:51:58 +0000 (12:51 +0100)
committerTomas Vondra <tomas.vondra@postgresql.org>
Thu, 20 Nov 2025 12:26:49 +0000 (13:26 +0100)
When running in Docker, the container may not have privileges needed by
get_mempolicy(). This is called by numa_available() in libnuma, but
versions prior to 2.0.19 did not expect that. The numa_available() call
seemingly succeeds, but then we get unexpected failures when trying to
query status of pages:

  postgres =# select * from pg_shmem_allocations_numa;
  ERROR:  XX000: failed NUMA pages inquiry status: Operation not
          permitted
  LOCATION:  pg_get_shmem_allocations_numa, shmem.c:691

The best solution is to call get_mempolicy() first, and proceed to
numa_available() only when it does not fail with EPERM. Otherwise we'd
need to treat older libnuma versions as insufficient, which seems a bit
too harsh, as this only affects containerized systems.

Fix by me, based on suggestions by Christoph. Backpatch to 18, where the
NUMA functions were introduced.

Reported-by: Christoph Berg <myon@debian.org>
Reviewed-by: Christoph Berg <myon@debian.org>
Discussion: https://postgr.es/m/aPDZOxjrmEo_1JRG@msg.df7cb.de
Backpatch-through: 18

src/port/pg_numa.c

index 3368a43a338264d2bb40f136fd7e7ba5560a59cc..540ada3f8efdbba0ae7e919ec8d05befbe39ce71 100644 (file)
 int
 pg_numa_init(void)
 {
-   int         r = numa_available();
+   int         r;
+
+   /*
+    * XXX libnuma versions before 2.0.19 don't handle EPERM by disabling
+    * NUMA, which then leads to unexpected failures later. This affects
+    * containers that disable get_mempolicy by a seccomp profile.
+    */
+   if (get_mempolicy(NULL, NULL, 0, 0, 0) < 0 && (errno == EPERM))
+       r = -1;
+   else
+       r = numa_available();
 
    return r;
 }