Process model

For DBAs and operators

Who forks whom

The postmaster creates shared memory, then starts the startup process (recovery), checkpointer, background writer, WAL writer, autovacuum launcher, logical replication launcher and, since PostgreSQL 18 with the default io_method = worker, the io worker processes. For each new connection it accepts the socket and forks a backend; the child then reads the startup packet, authenticates using pg_hba.conf, attaches to its database and serves the session until disconnect. The postmaster deliberately stays out of shared memory as far as possible, so it survives a backend crash.

Seeing the processes

SELECT pid, backend_type, usename, datname, state, wait_event_type, wait_event
  FROM pg_stat_activity
 ORDER BY backend_type, pid;

In ps the titles look like postgres: app appdb 10.0.0.5(51234) idle, postgres: checkpointer or postgres: io worker 0.

Connection slots

Shared memory holds one PGPROC slot per allowed connection (plus slots for background and autovacuum workers), sized at start-up from max_connections, so changing it requires a restart. The last superuser_reserved_connections (3) slots are kept for superusers, and reserved_connections (since PostgreSQL 16) for roles granted pg_use_reserved_connections. When everything is taken:

Connection logging in PostgreSQL 18

log_connections is now a list: receipt, authentication, authorization, setup_durations or all (on still means the first three). setup_durations adds a line showing where connection time went:

When a backend dies

If a backend exits abnormally (segfault, kill -9, the Linux OOM killer) the postmaster cannot know whether shared memory is consistent, so it terminates every other backend and reinitialises, replaying WAL from the last checkpoint:

All sessions are dropped, which is why a single OOM-killed query looks like a full outage. Set vm.overcommit_memory = 2 on dedicated hosts, and never kill -9 a backend: use pg_cancel_backend() or pg_terminate_backend().

Why poolers

• Fork plus authentication typically costs a few milliseconds; TLS and SCRAM add more.
• Each backend keeps private catalog caches (several MB with many tables) and, without huge pages, its own page-table entries for shared memory.
• Snapshots scan the proc array, and lock and LWLock contention grows with active sessions. Throughput usually peaks at a small multiple of CPU cores.

Use transaction-mode pooling (PgBouncer, pgcat, Odyssey) to keep active backends close to the core count, and set idle_in_transaction_session_timeout so forgotten transactions do not hold slots and snapshots.

PostgreSQL 18 source trail: postmaster.c documents connection forking, startup/shutdown supervision and backend-crash recovery.