Re: Draft for basic NUMA observability - Mailing list pgsql-hackers

From Patrick Stählin
Subject Re: Draft for basic NUMA observability
Date
Msg-id 5e55422c-3d63-4277-b12e-2f45b9437f53@packi.ch
Whole thread Raw
In response to Re: Draft for basic NUMA observability  (Tomas Vondra <tomas@vondra.me>)
Responses Re: Draft for basic NUMA observability
List pgsql-hackers
Hi!

On 4/7/25 11:27 PM, Tomas Vondra wrote:
> 
> I've pushed all three parts of v29, with some additional corrections
> (picked lower OIDs, bumped catversion, fixed commit messages).

While building the PG18 beta1/2 packages I noticed that in our build 
containers the selftest for pg_buffercache_numa and numa failed. It 
seems that libnuma was available and pg_numa_init/numa_available returns 
no errors, we still fail in pg_numa_query_pages/move_pages with EPERM 
yielding the following error when accessing 
pg_buffercache_numa/pg_shmem_allocations_numa:

   ERROR: failed NUMA pages inquiry: Operation not permitted

The man-page of move_pages lead me to believe that this is because of 
the missing capability CAP_SYS_NICE on the process but I couldn't prove 
that theory with the attached patch.
The patch did make the tests pass but also disabled NUMA permanently on 
a vanilla Debian VM and that is certainly not wanted. It may well be 
that my understanding of checking capabilities and how they work is 
incomplete. I also think that adding a new dependency for the reason of 
just checking the capability is probably a bit of an overkill, maybe we 
can check if we can access move_pages once without an error before 
treating it as one?

I'd be happy to debug this further but I have limited access to our 
build-infra, I should be able to sneak in commands during the build though.

Thanks,
Patrick
Attachment

pgsql-hackers by date:

Previous
From: Álvaro Herrera
Date:
Subject: Re: Log prefix missing for subscriber log messages received from publisher
Next
From: Shinya Kato
Date:
Subject: Re: Add backup_type to pg_stat_progress_basebackup