↑↓ select ↵ open ⌫ change scope Open full search

PG.CENTER connects PostgreSQL documentation, reference, and ecosystem knowledge. Maintained by Pigsty.

SQLSTATE / CLASS 53 · INSUFFICIENT RESOURCES

53200

Read PG 18 manual ↗

out_of_memory

SQLSTATE
53200
Condition name
out_of_memory
Class
Insufficient Resources
Source macro
ERRCODE_OUT_OF_MEMORY
Evidence
Source path confirmed
Analysis & operational context

English SQLSTATE atlas: authored explanations and source/runtime evidence are separate from the manual definitions. View source ↗

<h1>53200</h1>

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.

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.

Versions

The locked catalogue records this condition from 7.4; cited extension and core paths are PostgreSQL 18.6 source. No OOM runtime was attempted.

Sources

contrib/pg_stat_statements/pg_stat_statements.c#L2340-L2350

contrib/pg_walinspect/pg_walinspect.c#L121-L124

src/backend/access/transam/twophase.c#L1417-L1420

src/backend/utils/mmgr/aset.c#L444-L453

src/backend/utils/mmgr/mcxt.c#L1157-L1167

src/backend/storage/ipc/shmem.c#L151-L162

src/backend/storage/lmgr/lock.c#L2957-L2969

The structured evidence record records fixed messages and the source/runtime boundary.

Source evidence

Evidence belongs to the frozen source and runtime versions listed here. It is not a runtime verification of the selected manual version.

53200 is out_of_memory in SQLSTATE Class 53.

Method: Read fixed definition.

src.errcodes.18.6

The cited PostgreSQL 18.6 source paths support the representative resource and object-state mechanisms described.

Method: Read complete fixed source contexts.

Limits: Source confirmation is not natural runtime.

src.path.0 src.path.1 src.path.2 src.path.3 src.path.4 src.path.5 src.path.6

Core memory-context allocation uses 53200 for allocator failure, shared-memory allocation uses an out-of-shared-memory primary, and lock-table exhaustion can add a max_locks_per_transaction hint; these contexts are distinct from extension file/WAL allocation details.

Method: Read the complete fixed allocator, shared-memory, and lock-table guards.

src.path.3 src.path.4 src.path.5 src.path.6

The source report groups keep out of memory as the primary and the operation-specific allocation text as DETAIL; the pg_stat_statements group is LOG while the WAL reader groups are ERROR.

Method: Read fixed report groups and complete source contexts.

src.calls.REL_18_6

The locked catalogue records 53200 from 7.4; that boundary does not prove exact implementation introduction.

Method: Use catalogue boundary.

src.errcodes.18.6

Message templates

LOG · message.0

Primary

out of memory

Detail

Could not allocate enough memory to read file "%s".
ERROR · message.1

Primary

out of memory

Detail

Failed while allocating a WAL reading processor.
ERROR · message.2

Primary

out of memory

Detail

Failed while allocating a WAL reading processor.
ERROR · message.3

Primary

out of memory

Detail

Failed while creating memory context "%s".
ERROR · message.4

Primary

out of memory

Detail

Failed on request of size %zu in memory context "%s".
ERROR · message.5

Primary

out of shared memory (%zu bytes requested)
ERROR · message.6

Primary

out of shared memory

Hint

You might need to increase "max_locks_per_transaction".

Reproduction & repair cases

No reproduction case is attached to this condition.

Recorded runtime evidence

No runtime observation is attached to this entry.

Definition snapshot: english-manuals:789304e20db9bbcd50c12e50175… · English manual source