EC
57P03
PostgreSQLFATALCriticalOperator InterventionHIGH confidence

the database system is starting up

Production Risk

If 57P03 persists for an unusually long time (many minutes), it may indicate that WAL recovery is processing a large backlog or is stuck on a corrupt WAL segment. Monitor pg_last_wal_replay_lsn() progress and check server logs for recovery errors.

What this means

A client attempted to connect while Postgres is still in the startup/recovery phase and is not yet ready to accept connections. This is normal during server start or WAL replay after a crash and typically resolves on its own within seconds to minutes.

Why it happens
  1. 1Postgres server was just started and is still initialising shared memory or running startup checks
  2. 2Postgres is replaying WAL after an unclean shutdown (crash recovery)
  3. 3A standby replica is in recovery mode and has not reached a consistent state yet
  4. 4A pg_upgrade or pg_resetwal operation is in progress
How to reproduce

A connection is attempted immediately after server start before recovery is complete.

trigger — this will error
trigger — this will error
-- Cannot be triggered by SQL; occurs at connection time.
-- Check recovery status once connected:
SELECT pg_is_in_recovery();
SELECT pg_last_wal_replay_lsn();

expected output

FATAL:  the database system is starting up

Fix

Wait and retry the connection

WHEN Always — this is a transient condition that resolves when startup completes.

Wait and retry the connection
-- Application retry logic: poll pg_isready or attempt connection with backoff.
-- From the command line:
-- pg_isready -h localhost -p 5432
-- Returns exit code 0 when the server is ready to accept connections.

Why this works

During startup the postmaster goes through several phases (shared memory init, WAL recovery, checkpoint). It only starts accepting client connections after the startup process exits and the postmaster enters its main loop. pg_isready probes the connection without completing the startup protocol, making it safe to poll.

What not to do

✕ Immediately force-kill and restart Postgres when seeing 57P03

Interrupts WAL recovery, potentially leaving the database in a corrupt state that requires a more complex recovery.

Sources
Official documentation ↗

src/backend/postmaster/postmaster.c — ServerLoop()

pg_isready ↗Backup and Recovery ↗

Content generated with AI assistance and reviewed for accuracy. Found an error? hello@errcodes.dev

← All PostgreSQL errors