Re: pgsql: Introduce pg_shmem_allocations_numa view - Mailing list pgsql-hackers

From Andres Freund
Subject Re: pgsql: Introduce pg_shmem_allocations_numa view
Date
Msg-id g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn
Whole thread Raw
In response to Re: pgsql: Introduce pg_shmem_allocations_numa view  (Christoph Berg <myon@debian.org>)
List pgsql-hackers
Hi,

On 2025-06-23 16:48:27 +0200, Christoph Berg wrote:
> Re: To Tomas Vondra
> > Why do we try to force the pages to be allocated at all? This is just
> > a monitoring function, it should not change the actual system state.

The problem is that the kernel function just gives bogus results for pages
that *are* present in memory but that have only touched in another process
that has mapped the same range of memory.


> One-time touching might also not be enough, what if the pages later
> get swapped out and the monitoring functions are called again?

I don't think that's a problem, the process still has a relevant page table
entry in that case.

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: Nathan Bossart
Date:
Subject: Re: Improve CRC32C performance on SSE4.2