On Thu, Jan 29, 2026 at 12:43 PM Ashutosh Bapat <[email protected]> wrote: > The user could achieve the same effect by setting shared_buffers to > the same value as shared_buffers_autotune_target. What's the > difference? > > Further they can use -C and -c options to postgres to decide which > setting of shared_buffers will consume the desired amount of available > memory. That is quite quick and easy. > > I may be missing some usecase where such runtime autotuning is useful.
To give a concrete example, I have a pod with 30GB of huge pages. If I start postgres with "postgres -cshared_buffers=30GB -chuge_pages=on", it fails with: FATAL: could not map anonymous shared memory: Cannot allocate memory HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 32988200960 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing "shared_buffers" or "max_connections". With all the additional memory requests, ~30.7GB is requested. I need to lower the shared_buffers to 29.2GB to be able to start, but this is imprecise and with this value, I'm off by ~60 huge pages in the final allocation. The huge pages that were not part of the mmap are completely wasted since it can't even be used by Linux for the page cache. So the idea behind the autotune logic is to be able to provide a specific amount of shared memory to target and adjust shared_buffers accordingly. The huge pages I have reserved for the pod are only useful if they are used in the shared memory mmap, so the autotune makes sure that nothing is wasted. shared_buffers_autotune_target is probably confusing, shared_memory_autotune_target might be a more fitting name.
