Date: Mon, 23 Jun 2025 23:25:23 +0200
From: Christoph Berg <myon@debian.org>
To: Tomas Vondra <tomas@vondra.me>
Cc: Andres Freund <andres@anarazel.de>,
	Tomas Vondra <tomas.vondra@postgresql.org>,
	pgsql-hackers@lists.postgresql.org
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Message-ID: <aFnGQ2lfb8cfukim@msg.df7cb.de>
References: <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>
 <ce305c79-0a68-46ce-b563-ab9f87bb5f20@vondra.me>
 <aFm-ZfL-vz9I2Zmc@msg.df7cb.de>
 <0643ae61-cf9d-482c-9b2c-fb861b24fd22@vondra.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <0643ae61-cf9d-482c-9b2c-fb861b24fd22@vondra.me>
Archived-At: 
 <https://www.postgresql.org/message-id/aFnGQ2lfb8cfukim%40msg.df7cb.de>
Precedence: bulk

Re: Tomas Vondra
> True. If it fails on first call, but succeeds on the other, then the
> problem is likely somewhere else. But also on the second call we won't
> do the memory touching. Can you try setting firstNumaTouch=false, so
> that we do this on every call?

firstNumaTouch=false, it still fails on the first call.

I assume you meant actually keeping firstNumaTouch=true - but it still
fails on the first call.

The memory touching is done for the first call in each backend, but
reconnecting doesn't reset it, I have to restart PG.

> At the beginning you mentioned this is happening on i386, armel and
> armhf - are all those in qemu? I've tried on my rpi5 (with 32-bit user
> space), and there everything seems to work fine. But that's aarch64
> kernel, just the user space if 32-bit.

I'm testing on i386 in a chroot on a amd64 kernel. (same for x32)
armel and armhf are also 32-bit chroots on a arm64 host.

https://buildd.debian.org/status/package.php?p=postgresql-18&suite=experimental

Maybe this is a kernel bug.

Christoph