53200 — out_of_memory

Source-backed reference for PostgreSQL SQLSTATE 53200.

53200

At a glance

53200 is PostgreSQL’s out-of-memory condition. Fixed callers include ordinary memory-context allocation, shared-memory and lock-table capacity, extension/statistics-file loading, and WAL-reading processors. The useful diagnosis is the operation and allocation context, not a claim that every memory failure has one cause.

Field	Value
SQLSTATE	`53200`
Condition	`out_of_memory`
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_OUT_OF_MEMORY`
Aliases	`—`

Meaning

The fixed source has several distinct boundaries. MemoryContextAllocationFailure reports out of memory with the requested size and memory-context name, while ShmemAlloc and lock-table setup report out of shared memory; the latter can hint at max_locks_per_transaction. Extension paths add operation details: pg_stat_statements logs out of memory with a file-reading detail, and WAL readers report the same primary with an allocation detail. The pg_stat_statements branch is LOG and returns from its loader, so it is not the same as a client ERROR that aborts the current transaction; the core and WAL-reader ERROR branches require normal transaction recovery. The two-phase source path is a WAL-reader allocation path, not evidence that reaching max_prepared_transactions itself emits 53200.

Diagnosis

Preserve severity, primary, detail, hint, operation, backend, and server log. Determine whether the path was a backend memory-context request, shared-memory/lock-table allocation, file/statistics structure, or WAL reader. For out of shared memory with a max_locks_per_transaction hint, inspect transaction lock counts and the configured lock-table capacity; increasing it consumes shared memory at startup. Check workload and relevant limits from observation; do not infer a host-wide memory diagnosis from the SQLSTATE alone.

Response

Reduce or reshape the operation, release application-side pressure, or adjust the named PostgreSQL capacity after confirming its effect and platform limits. Finish or roll back transactions that hold excessive locks before changing max_locks_per_transaction; do not treat that hint as proof of operating-system OOM. For a failed file/WAL/statistics operation, validate the object before retrying. The core/WAL-reader ERROR branches leave an explicit transaction failed, so use ROLLBACK or ROLLBACK TO SAVEPOINT before retrying; autocommit retry is appropriate only after the allocation cause is corrected. The pg_stat_statements LOG branch is a backend loader path and does not itself require client transaction recovery. OOM and corruption tests are intentionally source-only here; do not force allocator failure on a live host.