Re: pgsql: Introduce pg_shmem_allocations_numa view

Re: To Tomas Vondra
> This is acting up on Debian's 32-bit architectures, namely i386, armel
> and armhf:

... and x32 (x86_64 instruction set with 32-bit pointers).

> SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
> +ERROR: invalid NUMA node id outside of allowed range [0, 0]: -14
>
> -14 seems to be -EFAULT, and move_pages(2) says:
> -EFAULT
> This is a zero page or the memory area is not mapped by the process.

I did some debugging on i386 and made it print the page numbers:

SELECT COUNT(*) >= 0 AS ok FROM pg_shmem_allocations_numa;
+WARNING: invalid NUMA node id outside of allowed range [0, 0]: -14 for page 35
+WARNING: invalid NUMA node id outside of allowed range [0, 0]: -14 for page 36
...
+WARNING: invalid NUMA node id outside of allowed range [0, 0]: -14 for page 32768
+WARNING: invalid NUMA node id outside of allowed range [0, 0]: -14 for page 32769

So it works for the first few pages and then the rest is EFAULT.

I think the pg_numa_touch_mem_if_required() hack might not be enough
to force the pages to be allocated. Changing that to a memcpy() didn't
help. Is there some optimization that zero pages aren't allocated
until being written to?

Why do we try to force the pages to be allocated at all? This is just
a monitoring function, it should not change the actual system state.
Why not just skip any page where the status is <0 ?

The attached patch removes that logic. Regression tests pass, but we
probably have to think about whether to report these negative numbers
as-is or perhaps convert them to NULL.

Christoph