Re: pgsql: Introduce pg_shmem_allocations_numa view

Christoph Berg <myon@debian.org>

From: Christoph Berg <myon@debian.org>

To: Tomas Vondra <tomas.vondra@postgresql.org>

Cc: pgsql-hackers@lists.postgresql.org

Date: 2025-06-23T14:48:27Z

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

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.

One-time touching might also not be enough, what if the pages later
get swapped out and the monitoring functions are called again? They
will have to deal with these "not in memory" error conditions anyway.

Christoph