Re: pgsql: Introduce pg_shmem_allocations_numa view
От | Tomas Vondra |
---|---|
Тема | Re: pgsql: Introduce pg_shmem_allocations_numa view |
Дата | |
Msg-id | cd16c4a3-2860-46de-a74e-5532d1b2ee39@vondra.me обсуждение исходный текст |
Ответ на | Re: pgsql: Introduce pg_shmem_allocations_numa view (Christoph Berg <myon@debian.org>) |
Ответы |
Re: pgsql: Introduce pg_shmem_allocations_numa view
|
Список | pgsql-hackers |
On 6/23/25 23:25, Christoph Berg wrote: > 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. > No, I meant firstNumaTouch=false, so that the touching happens on every call. I was wondering if that makes all calls fail. > The memory touching is done for the first call in each backend, but > reconnecting doesn't reset it, I have to restart PG. > I don't follow. Why wouldn't reconnecting reset it? >> 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. > Or maybe the 32-bit chroot on 64-bit host matters and confuses some calculation. -- Tomas Vondra
В списке pgsql-hackers по дате отправления: