Connecting the OS Pool to the Database
Allocating HugePages at the OS level is only half the job. You must also configure Postgres to request memory from the HugeTLB pool rather than using standard malloc.
Two settings in postgresql.conf control this: shared_buffers, which sizes the buffer pool that will be backed by HugePages, and huge_pages, which controls HugePage behavior — try uses HugePages if available and silently falls back to 4KB pages if not (the default), on requires HugePages and refuses to start without them, and off never uses them.
huge_pages = try vs huge_pages = on:
try is the safe default — if your vm.nr_hugepages is misconfigured, Postgres starts anyway using standard pages. You get no performance benefit but also no outage.
on is the production-correct setting. If vm.nr_hugepages is insufficient, Postgres refuses to start with a fatal "could not map anonymous shared memory" error rather than silently degrading.
This is actually desirable in production — it forces you to notice and fix the misconfiguration rather than silently running with degraded performance.
Verifying Postgres is using HugePages after startup: check the checkpointer process's memory maps for hugetlb entries, or simply watch whether HugePages_Free in /proc/meminfo drops significantly once Postgres starts.