Re: pgsql: Introduce pg_shmem_allocations_numa view

From: Christoph Berg <myon(at)debian(dot)org>
To: Tomas Vondra <tomas(at)vondra(dot)me>
Cc: Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tomas(dot)vondra(at)postgresql(dot)org>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: pgsql: Introduce pg_shmem_allocations_numa view
Date: 2025-06-23 21:25:23
Message-ID: aFnGQ2lfb8cfukim@msg.df7cb.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-committers 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

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Tomas Vondra 2025-06-23 21:47:00 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message Tomas Vondra 2025-06-23 21:14:28 Re: pgsql: Introduce pg_shmem_allocations_numa view

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-06-23 21:47:00 Re: pgsql: Introduce pg_shmem_allocations_numa view
Previous Message Tomas Vondra 2025-06-23 21:14:28 Re: pgsql: Introduce pg_shmem_allocations_numa view