Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uTnpl-00A8rE-HE for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jun 2025 20:32:05 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1uTnpj-006Phv-Bh for pgsql-hackers@arkaria.postgresql.org; Mon, 23 Jun 2025 20:32:03 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1uTnpi-006Phn-UO for pgsql-hackers@lists.postgresql.org; Mon, 23 Jun 2025 20:32:03 +0000 Received: from mout-p-101.mailbox.org ([2001:67c:2050:0:465::101]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1uTnph-003bin-1K for pgsql-hackers@lists.postgresql.org; Mon, 23 Jun 2025 20:32:02 +0000 Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-101.mailbox.org (Postfix) with ESMTPS id 4bR09g6vVLz9sWN; Mon, 23 Jun 2025 22:31:51 +0200 (CEST) Date: Mon, 23 Jun 2025 22:31:50 +0200 From: Christoph Berg To: Tomas Vondra Cc: Andres Freund , Tomas Vondra , pgsql-hackers@lists.postgresql.org Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view Message-ID: References: <6c9f9f7e-947b-4fc3-bdb6-b0696d7492e5@vondra.me> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6c9f9f7e-947b-4fc3-bdb6-b0696d7492e5@vondra.me> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk 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