Re: pgsql: Introduce pg_shmem_allocations_numa view
От | Christoph Berg |
---|---|
Тема | Re: pgsql: Introduce pg_shmem_allocations_numa view |
Дата | |
Msg-id | aFnGQ2lfb8cfukim@msg.df7cb.de обсуждение исходный текст |
Ответ на | Re: pgsql: Introduce pg_shmem_allocations_numa view (Tomas Vondra <tomas@vondra.me>) |
Ответы |
Re: pgsql: Introduce pg_shmem_allocations_numa view
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: