shared_buffers

For DBAs and operators

Allocated once at startup in the main shared memory segment (one 8 kB buffer plus a ~64-byte descriptor per page). The default 128MB is a placeholder: for a dedicated server start at about 25% of RAM; going beyond ~40% rarely helps because PostgreSQL also relies on the OS page cache (data is often cached twice). Very large values need more max_wal_size so checkpoints can spread writes, and benefit a lot from huge_pages (page tables for a 64 GB segment otherwise cost gigabytes across many backends).

Observe

SHOW shared_memory_size;                -- total main segment
SHOW shared_memory_size_in_huge_pages;  -- huge pages to reserve
SELECT datname, blks_hit, blks_read,
       round(100.0*blks_hit/nullif(blks_hit+blks_read,0),2) AS hit_pct
  FROM pg_stat_database;
-- per backend type / context, including evictions:
SELECT backend_type, context, reads, hits, evictions, writes
  FROM pg_stat_io WHERE object = 'relation';

A "read" is only a miss in shared buffers; it may still be served from the OS cache. EXPLAIN (ANALYZE, BUFFERS) shows shared hit/read/dirtied/written per node, and the pg_buffercache extension shows what is cached.

Pitfalls

• Sequential scans of big tables, VACUUM and COPY use a small ring buffer, so one big scan does not flush the cache (see vacuum_buffer_usage_limit).
• If the kernel cannot provide the segment the server will not start: FATAL: could not map anonymous shared memory: Cannot allocate memory. With huge_pages = on and too few pages reserved you get the same at startup.
• In containers, count shared_buffers against the memory limit together with work_mem × connections.

How to change it

Change in postgresql.conf or ALTER SYSTEM, then restart the server.