public inbox for [email protected]
help / color / mirror / Atom feedFrom: Tomas Vondra <[email protected]>
To: Christoph Berg <[email protected]>
Cc: Andres Freund <[email protected]>
Cc: Tomas Vondra <[email protected]>
Cc: [email protected]
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Date: Mon, 23 Jun 2025 22:37:12 +0200
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<g3mywoeo7jmh6rci7epx2ishowgz65q2j7ek3c5f3lxcmvuktg@ler2fsv4szmn>
<[email protected]>
<[email protected]>
<kl4zd72eeaex7zcicpuvpsuslrs5nfvmab7xzt4jnvcjvd6mxw@tcp64c55qkpj>
<[email protected]>
<[email protected]>
<[email protected]>
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
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