> On Fri, May 17, 2024 at 01:13:06PM +0000, PG Bug reporting form wrote:
> The following bug has been logged on the website:
>
> Bug reference: 18471
> Logged by: Joachim Haecker-Becker
> Email address: joachim.haecker-becker@arcor.de
> PostgreSQL version: 16.3
> Operating system: Debian Bookworm
> Description:
>
> We have a reproducible way to force a postgres process to consume more and
> more RAM until it crashes on ARM.
> The same works on X86 without any issue.
> With jit=off it runs on ARM as well.
>
> We run into this situation in a real-life database situation with a lot of
> joins and aggregate functions.
> The following code is just a mock to reproduce a similar situation without
> needing access to our real data.
> This issue blocks us from upgrading or ARM-hosted databases into something
> newer than 14.7.

I think it would be useful to know how much memory difference are we
talking about and, just to make everything clear, how exactly postgres
crashes (OOM kill I assume)? It's important to differentiate between the
case "ARM with jit crashes, ARM without jit doesn't" and "ARM with jit
crashes, ARM without jit crashes with even more columns" (the same goes
for x86).

I've tried to reproduce it on an arm64 VM (16.3 build with llvm 17), and
although I could observe some difference in memory consumption between
JIT on/off, but it wasn't huge (around 10% or so). Running it under
valgrind shows only complains about memory allocated for bitcode
modules, which is expected -- as far as I recall postgres is somewhat
wasteful when it comes to allocating memory for those modules, even more
so for parallel workers. This is the case here, where there is growing
number of parallel hash workers. This would not explain any difference
from x86 of course, but there might be different baseline memory
consumption for different architectures.