Re: pgsql: Introduce pg_shmem_allocations_numa view

Christoph Berg <myon@debian.org>

From: Christoph Berg <myon@debian.org>
To: Tomas Vondra <tomas@vondra.me>
Cc: Andres Freund <andres@anarazel.de>, Tomas Vondra <tomas.vondra@postgresql.org>, pgsql-hackers@lists.postgresql.org
Date: 2025-06-23T20:31:50Z
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 →
  1. Handle EPERM in pg_numa_init

  2. Add CHECK_FOR_INTERRUPTS into pg_numa_query_pages

  3. Silence valgrind about pg_numa_touch_mem_if_required

  4. Limit the size of numa_move_pages requests

  5. Introduce pg_shmem_allocations_numa view

Re: Tomas Vondra
> Huh. So it's only the first call that does this?

The first call after a restart. Reconnecting is not enough.

> Can you maybe print the addresses passed to pg_numa_query_pages? I

The addresses look good:

Breakpoint 1, pg_numa_query_pages (pid=0, count=32768, pages=0xeb44d02c, status=0xeb42c02c) at ../src/port/pg_numa.c:49
49		return numa_move_pages(pid, count, pages, NULL, status, 0);
(gdb) p *pages
$1 = (void *) 0xebc33000
(gdb) p pages[1]
$2 = (void *) 0xebc34000
(gdb) p pages[2]
$3 = (void *) 0xebc35000


> wonder if there's some bug in how we fill that array. Not sure why would
> it happen only on 32-bit systems, though.

I found something, but that should be harmless:

--- a/contrib/pg_buffercache/pg_buffercache_pages.c
+++ b/contrib/pg_buffercache/pg_buffercache_pages.c
@@ -365,7 +365,7 @@ pg_buffercache_numa_pages(PG_FUNCTION_ARGS)

 		/* Used to determine the NUMA node for all OS pages at once */
 		os_page_ptrs = palloc0(sizeof(void *) * os_page_count);
-		os_page_status = palloc(sizeof(uint64) * os_page_count);
+		os_page_status = palloc(sizeof(int) * os_page_count);

 		/* Fill pointers for all the memory pages. */
 		idx = 0;

Christoph