Re: Draft for basic NUMA observability

Hi,

On Mon, Apr 07, 2025 at 12:42:21PM -0400, Andres Freund wrote:
> Hi,
>
> On 2025-04-07 18:36:24 +0200, Tomas Vondra wrote:
>
> I was thinking of checking if the BufferDesc indicates BM_VALID or
> BM_TAG_VALID.

Yeah, that's what I did propose in [1] (when we were speaking about get_mempolicy())
and I think that would make sense as future improvement.

>
>
> > I think we need to decide whether the current patches are good enough
> > for PG18, with the current behavior, and then maybe improve that in
> > PG19.
>
> I think as long as the docs mention this with <note> or <warning> it's ok for
> now.

+1

A few comments on v27:

=== 1

pg_buffercache_numa() reports the node ID as "nodeid" while pg_shmem_allocations_numa()
reports it as node_id. Maybe we should use the same "naming" in both.

=== 2

postgres=# select count(*) from pg_buffercache;
count
-------
65536
(1 row)

but

postgres=# select count(*) from pg_buffercache_numa;
count
-------
64
(1 row)

with:

postgres=# show block_size;
block_size
------------
2048

and Hugepagesize: 2048 kB.

and

postgres=# show shared_buffers;
shared_buffers
----------------
128MB
(1 row)

And even if for testing I set:

- funcctx->max_calls = idx;
+ funcctx->max_calls = 65536;

then I start to see weird results:

postgres=# select count(*) from pg_buffercache_numa where bufferid not in (select bufferid from pg_buffercache);
count
-------
65472
(1 row)

So it looks like that the new way to iterate on the buffers that has been introduced
in v26/v27 has some issue?

[1]: https://www.postgresql.org/message-id/Z64Pr8CTG0RTrGR3%40ip-10-97-1-34.eu-west-3.compute.internal

Regards,

--
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com