Search across all documentation pages
PostgreSQL is a multi-process server: a supervising postmaster forks backend processes per client connection while background workers maintain durability and cache hygiene. Understanding this split explains connection limits, memory sizing, and why restarts vs reloads differ.
-- See live backends and what they run
SELECT pid, usename, application_name, state, wait_event_type, query
FROM pg_stat_activity
WHERE backend_type = 'client backend'
ORDER BY state, pid;# Reload config without dropping connections (many GUCs)
pg_ctl reload -D /var/lib/postgresql/18/main
# Full restart recycles postmaster and all children
pg_ctl restart -D /var/lib/postgresql/18/mainWhen to reach for this: You need to reason about connections, memory, checkpoints, or why a setting requires a restart.
-- WAL generation rate hint (bytes per checkpoint cycle)
SELECT checkpoints_timed, checkpoints_req,
wal_bytes, buffers_checkpoint
FROM pg_stat_bgwriter;
-- Shared buffer hit ratio (database level)
SELECT sum(blks_hit)::float / nullif(sum(blks_hit) + sum(blks_read), 0) AS cache_hit_ratio
FROM pg_stat_database;What this demonstrates:
pg_stat_activity separates client backends from background workerspg_stat_bgwriter exposes checkpoint and WAL volume| Alternative | Use When | Don't Use When |
|---|---|---|
| Connection pooler (PgBouncer) | Many short-lived app connections | You need prepared statements pinned to one backend in transaction mode |
| Managed Postgres (RDS, Cloud SQL) | Ops team wants patching and backups handled | You need custom extensions or kernel tuning |
| Read replicas | Read-heavy reporting off primary | Synchronous replication adds commit latency |
Reload re-reads postgresql.conf for many parameters. Restart recycles all processes and is required for memory-related GUCs.
Depends on RAM and workload. Hundreds of idle connections are cheap; hundreds of active queries are not. Pool aggressively.
The data directory (PGDATA) holds heap files, WAL, and catalog. Use tablespaces only when you need separate storage paths.
No for backends. Parallel query workers are separate processes forked for a single statement.
On startup, Postgres replays WAL from the last checkpoint, then accepts connections.
Stack versions: This page was written for PostgreSQL 18.4 (stable 18, maintenance 17), pgvector 0.8+, PgBouncer 1.x, Patroni 3.x, and PostGIS 3.5+.
Reviewed by Chris St. John·Last updated Jul 18, 2026