Re: pgsql: Introduce pg_shmem_allocations_numa view

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Christoph Berg <myon@debian.org>

Cc: Tomas Vondra <tomas.vondra@postgresql.org>, pgsql-hackers@lists.postgresql.org

Date: 2025-06-23T15:14:54Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Handle EPERM in pg_numa_init
- 599336c64fc9 19 (unreleased) landed
- 482e98ac4302 18.2 landed
Add CHECK_FOR_INTERRUPTS into pg_numa_query_pages
- 54ac4944c36f 18.0 landed
- bf1119d74a79 19 (unreleased) landed
Silence valgrind about pg_numa_touch_mem_if_required
- 14e52227e578 18.0 landed
- 81f287dc923f 19 (unreleased) landed
Limit the size of numa_move_pages requests
- 45879f48f140 18.0 landed
- 7fe2f67c7c9f 19 (unreleased) landed
Introduce pg_shmem_allocations_numa view
- 8cc139bec34a 18.0 cited

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