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