Re: pgsql: Introduce pg_shmem_allocations_numa view

Hi,

On 2025-06-24 03:43:19 +0200, Tomas Vondra wrote:
> FWIW while looking into this, I tried running this under valgrind (on a
> regular 64-bit system, not in the chroot), and I get this report:
> 
> ==65065== Invalid read of size 8
> ==65065==    at 0x113B0EBE: pg_buffercache_numa_pages
> (pg_buffercache_pages.c:380)
> ==65065==    by 0x6B539D: ExecMakeTableFunctionResult (execSRF.c:234)
> ==65065==    by 0x6CEB7E: FunctionNext (nodeFunctionscan.c:94)
> ==65065==    by 0x6B6ACA: ExecScanFetch (execScan.h:126)
> ==65065==    by 0x6B6B31: ExecScanExtended (execScan.h:170)
> ==65065==    by 0x6B6C9D: ExecScan (execScan.c:59)
> ==65065==    by 0x6CEF0F: ExecFunctionScan (nodeFunctionscan.c:269)
> ==65065==    by 0x6B29FA: ExecProcNodeFirst (execProcnode.c:469)
> ==65065==    by 0x6A6F56: ExecProcNode (executor.h:313)
> ==65065==    by 0x6A9533: ExecutePlan (execMain.c:1679)
> ==65065==    by 0x6A7422: standard_ExecutorRun (execMain.c:367)
> ==65065==    by 0x6A7330: ExecutorRun (execMain.c:304)
> ==65065==    by 0x934EF0: PortalRunSelect (pquery.c:921)
> ==65065==    by 0x934BD8: PortalRun (pquery.c:765)
> ==65065==    by 0x92E4CD: exec_simple_query (postgres.c:1273)
> ==65065==    by 0x93301E: PostgresMain (postgres.c:4766)
> ==65065==    by 0x92A88B: BackendMain (backend_startup.c:124)
> ==65065==    by 0x85A7C7: postmaster_child_launch (launch_backend.c:290)
> ==65065==    by 0x860111: BackendStartup (postmaster.c:3580)
> ==65065==    by 0x85DE6F: ServerLoop (postmaster.c:1702)
> ==65065==  Address 0x7b6c000 is in a rw- anonymous segment
> 
> 
> This fails here (on the pg_numa_touch_mem_if_required call):
> 
>     for (char *ptr = startptr; ptr < endptr; ptr += os_page_size)
>     {
>         os_page_ptrs[idx++] = ptr;
> 
>         /* Only need to touch memory once per backend process */
>         if (firstNumaTouch)
>             pg_numa_touch_mem_if_required(touch, ptr);
>     }

That's because we mark unpinned pages as inaccessible / mark them as
accessible when pinning. See logic related to that in PinBuffer():

				/*
				 * Assume that we acquired a buffer pin for the purposes of
				 * Valgrind buffer client checks (even in !result case) to
				 * keep things simple.  Buffers that are unsafe to access are
				 * not generally guaranteed to be marked undefined or
				 * non-accessible in any case.
				 */


> The 0x7b6c000 is the very first pointer, and it's the only pointer that
> triggers this warning.

I suspect that that's because valgrind combines different reports or such.

Greetings,

Andres Freund