# 57P03 — cannot_connect_now

> Source-backed full entry for PostgreSQL SQLSTATE 57P03.
---

# 57P03

## At a glance {#at-a-glance}
`57P03` is emitted during connection startup when the database has not reached a connection-ready state. Fixed guards distinguish startup, shutdown, recovery, disabled hot standby, and two different not-yet-consistent recovery states.

<!-- BEGIN SQLSTATE FACTS: generated by scripts/generate.py; do not edit -->

| Field | Value |
| --- | --- |
| SQLSTATE | `57P03` |
| Condition | `cannot_connect_now` |
| Status | `active` |
| Known present by | `7.4` |
| Locked snapshots | `9.0.23, 9.1.24, 9.2.24, 9.3.25, 9.4.26, 9.5.25, 9.6.24, 10.23, 11.22, 12.22, 13.23, 14.24, 15.19, 16.15, 17.11, 18.6, 19beta3` |
| Macros | `ERRCODE_CANNOT_CONNECT_NOW` |
| Aliases | `—` |

<!-- source facts: data/errcodes/57P03.json -->
<!-- END SQLSTATE FACTS -->

## Meaning {#meaning}
The startup packet is rejected before normal authentication is completed. Every fixed branch uses FATAL, so the attempted connection ends rather than entering a client transaction. The primary alone is not enough for the hot-standby branches: detail distinguishes a disabled feature, a recovery snapshot that is not ready, and recovery that has not reached a consistent state.

## Messages {#messages}

- Startup gate: primary `the database system is starting up`, FATAL.
- Hot standby disabled: primary `the database system is not accepting connections`, FATAL; detail `Hot standby mode is disabled.`
- Recovery snapshot not ready: primary `the database system is not yet accepting connections`, FATAL; detail `Recovery snapshot is not yet ready for hot standby.`; hint `To enable hot standby, close write transactions with more than %d subtransactions on the primary server.`
- Recovery not consistent: primary `the database system is not yet accepting connections`, FATAL; detail `Consistent recovery state has not been yet reached.`
- Shutdown gate: primary `the database system is shutting down`, FATAL.
- Recovery gate: primary `the database system is in recovery mode`, FATAL.

## Diagnosis {#diagnosis}
Capture primary/detail/hint, the startup phase, hot-standby setting, recovery consistency/snapshot state, server readiness log, and target server role. A repeated `not yet accepting` response with the snapshot detail points to the primary-side subtransaction condition named by the hint; the consistent-recovery detail points to an earlier recovery gate. Do not treat these as a transaction stuck in `INERROR`: the connection was refused before a session transaction existed.

## Response {#response}
Use bounded backoff and wait for the relevant startup, shutdown, or recovery transition. If hot standby is intentionally disabled, remember that `hot_standby` is a `PGC_POSTMASTER` setting: change the configuration source owned by the server and restart the server; a SIGHUP/reload cannot activate this setting. If the hint identifies long primary write transactions, resolve that operational cause. Establish a new connection after readiness. There is no transaction on the rejected startup path to roll back; if a prior client operation was disconnected during a transition, verify its business result before replaying it.

## Versions {#versions}
The locked catalogue records this condition from 7.4; that boundary does not prove the exact implementation-introduction version. Fixed source coverage is PostgreSQL 18.6.

## Related {#related}
[`57P01`](../57p01/), [`57P04`](../57p04/), [`08001`](../08001/)

## Sources {#sources}
[`src/backend/tcop/backend_startup.c#L298-338`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/tcop/backend_startup.c#L298)

[`src/backend/utils/misc/guc_tables.c#L1895-1903`](https://github.com/postgres/postgres/blob/724edf9bde9d356724ad384a2e196edc3c9f80f7/src/backend/utils/misc/guc_tables.c#L1895)

The structured [evidence record](../data/evidence/57p03.json) records all fixed startup gates and the source/runtime boundary.