Re: failed NUMA pages inquiry status: Operation not permitted - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: failed NUMA pages inquiry status: Operation not permitted
Date
Msg-id f1af27db-4e59-4c6b-9d8c-6f667186563a@vondra.me
Whole thread Raw
In response to Re: failed NUMA pages inquiry status: Operation not permitted  (Christoph Berg <myon@debian.org>)
List pgsql-hackers

On 12/16/25 18:54, Christoph Berg wrote:
> Re: Tomas Vondra
>> 1) right after opening a connection, I get this
>>
>> test=# select numa_node, count(*) from pg_buffercache_numa group by 1;
>>  numa_node | count
>> -----------+-------
>>          0 |   290
>>         -2 | 32478
> 
> Does that mean that the "touch all pages" logic is missing in some
> code paths?
> 

I did check and AFAICS we are touching the pages in pg_buffercache_numa.

To make it even more confusing, I can no longer reproduce the behavior I
reported yesterday. It just consistently reports "0" and I have no idea
why it changed :-( I did restart since yesterday, so maybe that changed
something.

> But even with that, it seems to be able to degenerate again and
> accepting -2 in the regression tests would be required to make it
> stable.
> 

No opinion yet. Either the -2 can happen occasionally, and then we'd
need to adjust the regression tests. Or maybe it's some thinko, and then
it'd be good to figure out why it's happening.

I find it interesting it does not seem to fail on the buildfarm. Or at
least I'm not aware of such failures. Even a rare failure should show
itself on the buildfarm a couple times, so how come it didn't?


regards

-- 
Tomas Vondra




pgsql-hackers by date:

Previous
From: Ashutosh Bapat
Date:
Subject: Re: apply_scanjoin_target_to_paths and partitionwise join
Next
From: "Zhijie Hou (Fujitsu)"
Date:
Subject: RE: Improve logical replication usability when tables lack primary keys