Why PostgreSQL Keeps Working After the Main Process Crashes

PostgreSQL’s design separates the postmaster (the main server process) from backend processes that handle client sessions. The postmaster only listens for new connections, while each backend maintains its own session and can perform WAL writes, buffer flushes, and other operations independently.

Experiment Setup

A test table is created, then the postmaster process is deliberately killed. Screenshots show the state of the system after the kill, leaving only the backend and logger processes running (the WAL and shared buffers remain in memory).

While the postmaster is down, a client connected through an existing backend session continues to execute INSERT statements successfully, demonstrating that the backend can still write to the database.

Observations After Restart

When the database is restarted, the previously inserted rows are missing. The loss occurs because the transaction was asynchronous and the WAL writer process, which periodically flushes the WAL buffer, was not running; the backend only flushes the buffer when it cannot obtain one, so the WAL entry was never persisted.

Using a synchronous transaction (setting synchronous_commit = on) ensures that the WAL is flushed before the transaction completes, preventing data loss even after the postmaster crash.

Limitations of Backend‑Only Operations

Although a backend can write to the WAL and shared buffers, it cannot perform a checkpoint; that responsibility belongs to the checkpoint process. If a large operation triggers a checkpoint while the postmaster is down, the log will show an error indicating the checkpoint could not be performed.

Other auxiliary processes such as autovacuum and the statistics collector also disappear when the postmaster is killed, causing related maintenance tasks and statistics collection to fail.

Monitoring Implications

Relying on long‑lived connections to monitor database health may not reveal postmaster failures. Short‑lived connections can detect whether the postmaster is alive, but they risk exhausting connection slots. A combined approach using both long and short connections provides more comprehensive monitoring.

Crash‑Restart Parameter

PostgreSQL provides the restart_after_crash (boolean) setting, which controls automatic restart behavior after a crash. Certain code paths in src/backend/postmaster/postmaster.c can trigger a restart under specific conditions.

For example, if the autovacuum process is killed, all backend processes are disconnected, and the autovacuum launcher must be restarted manually.

Overall, PostgreSQL’s multi‑process architecture ensures that ongoing sessions can survive a postmaster crash, but certain background tasks and durability guarantees depend on the presence of the main process and its auxiliary workers.