Message-ID: <ce305c79-0a68-46ce-b563-ab9f87bb5f20@vondra.me>
Date: Mon, 23 Jun 2025 22:37:12 +0200
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
To: Christoph Berg <myon@debian.org>
Cc: Andres Freund <andres@anarazel.de>,
 Tomas Vondra <tomas.vondra@postgresql.org>,
 pgsql-hackers@lists.postgresql.org
References: <E1u1tr8-003BbN-2E@gemulon.postgresql.org>
 <aEtDozLmtZddARdB@msg.df7cb.de> <aFln0lUZke2eEZsP@msg.df7cb.de>
 <aFlpO2lBsMjqarbp@msg.df7cb.de>
 <g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
 <aFlwrNqKjHC1vj8h@msg.df7cb.de> <aFl53B_JNN3i-viX@msg.df7cb.de>
 <kl4zd72eeaex7zcicpuvpsuslrs5nfvmab7xzt4jnvcjvd6mxw@tcp64c55qkpj>
 <aFmxxHVS9XwbQ_em@msg.df7cb.de>
 <6c9f9f7e-947b-4fc3-bdb6-b0696d7492e5@vondra.me>
 <aFm5tmSFwhGX7mA7@msg.df7cb.de>
Content-Language: en-US
From: Tomas Vondra <tomas@vondra.me>
In-Reply-To: <aFm5tmSFwhGX7mA7@msg.df7cb.de>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Archived-At: 
 <https://www.postgresql.org/message-id/ce305c79-0a68-46ce-b563-ab9f87bb5f20%40vondra.me>
Precedence: bulk


On 6/23/25 22:31, Christoph Berg wrote:
> 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
> 

Didn't you say the first ~35 addresses succeed, right? What about the
addresses after that?

> 
>> 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);
> 

Yes, good catch. But as you say, that should be benign - we allocate
more memory than needed, I don't think it should break anything.


-- 
Tomas Vondra