public inbox for [email protected]  

help / color / mirror / Atom feed

From: Tomas Vondra <[email protected]>
To: Andres Freund <[email protected]>
Cc: Christoph Berg <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Date: Tue, 24 Jun 2025 14:42:43 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <wzwr3igec6lniweml4j3s75fim6sss7lv5lvu67czm2mq73l6i@x6lddlso4n4u>
References: <kl4zd72eeaex7zcicpuvpsuslrs5nfvmab7xzt4jnvcjvd6mxw@tcp64c55qkpj>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<[email protected]>
	<wzwr3igec6lniweml4j3s75fim6sss7lv5lvu67czm2mq73l6i@x6lddlso4n4u>



On 6/24/25 13:10, Andres Freund wrote:
> 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.
> 

Thanks. It probably is something like that, although I made sure to not
use any such options when running valgrind (so --error-limit=no). But
maybe there's something else, hiding the reports.

I guess there are two ways to address this - make sure the buffers are
marked as accessible/defined, or add a valgrind suppression. I think the
suppression is the right approach here, otherwise we'd need to worry
about already pinned buffers etc. Which seems not great, the functions
don't even care about buffers right now, they mostly work with memory
pages (especially pg_shmem_allocations_numa).

Barring objections, I'll fix it this way.


regards

-- 
Tomas Vondra

view thread (83+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
  Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
  In-Reply-To: <[email protected]>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox