PostgreSQL raises error 53200 when a backend or operation cannot obtain enough RAM from the operating system or the configured memory pools.
PostgreSQL Error 53200 (out_of_memory) appears when a query or maintenance task exhausts available RAM. Increase work_mem or maintenance_work_mem, lower parallel workers, or add server memory to resolve the error.
PostgreSQL Error 53200
Error 53200 signals that PostgreSQL attempted to allocate memory but the request failed. The server cancels the current statement to protect overall stability.
The failure can occur in user sessions, autovacuum workers, or background processes. PostgreSQL maps most allocations to work_mem, maintenance_work_mem, shared_buffers, or the operating system page cache. When limits are hit, the out_of_memory condition is raised.
Large sort or hash operations that exceed work_mem trigger the error quickly.
Complex queries with many joins, ORDER BY clauses, or DISTINCT operations are common culprits.
Maintenance routines such as VACUUM FULL or CREATE INDEX rely on maintenance_work_mem. Undersized settings combined with big tables can exhaust memory and raise 53200.
Parallel query workers multiply the memory each backend uses.
A seemingly modest query may demand dozens of megabytes per worker, saturating RAM.
System-level limits like cgroup quotas, Docker memory caps, or misconfigured overcommit on Linux may cut PostgreSQL off from free RAM even when the server appears idle.
First, identify which allocation failed by checking the PostgreSQL log. Logs list the SQL statement and memory context where the failure occurred.
Increase work_mem for sessions that need large sorts.
For example: SET work_mem = '256MB'; Use conservative values in shared_conf to avoid over-allocation.
For index builds or VACUUM FULL, raise maintenance_work_mem temporarily or globally. Example: ALTER SYSTEM SET maintenance_work_mem = '1GB'; SELECT pg_reload_conf();
If parallelism is enabled, cap max_parallel_workers_per_gather or max_worker_processes to reduce aggregate memory demand.
On virtualised or containerised hosts, lift cgroup memory limits or provision more RAM.
Ensure Linux vm.overcommit_memory is 0 or 1 so allocations succeed.
Query with huge ORDER BY - Rewrite to use indexes or add LIMIT clauses.
Increase work_mem only after optimisation fails.
CREATE INDEX CONCURRENTLY on large table - Temporarily set maintenance_work_mem to a higher value and run off-peak.
Autovacuum crash - Raise autovacuum_work_mem or disable parallel vacuum in large partitions.
Parallel Hash Join spike - Lower hash_mem_multiplier to keep hash tables smaller.
Size work_mem at 1-2 per cent of total RAM multiplied by active connections to stay within physical memory.
Monitor pg_stat_activity and pg_stat_database_conflicts for early memory warnings.
Tools like Galaxy surface these stats alongside query text for faster diagnosis.
Create indexes to avoid large in-memory sorts and hashes.
The planner will stream data through indexes instead of allocating extra RAM.
Set alerting on Linux OOM killer events and PostgreSQL error 53200 to respond before sessions pile up.
Error 53100 disk_full - Similar resource shortage but on storage; add disk or clean WAL.
ERROR: cannot allocate memory for node array - Triggered inside planner when statistics need more memory; update statistics and raise work_mem.
ERROR: out of shared memory - Indicates insufficient shared memory slots; increase max_locks_per_transaction or max_pred_locks_per_transaction.
.
Queries with ORDER BY, DISTINCT, or window functions can exceed work_mem when datasets are wide or unfiltered.
Hash tables must fit in memory. When they cannot, PostgreSQL spills or throws out_of_memory if spill is disabled or impossible.
CREATE INDEX, VACUUM FULL, and CLUSTER depend on maintenance_work_mem.
Large tables can exhaust this setting quickly.
Each worker copies the session's work_mem, multiplying memory usage beyond expectations.
Container memory caps, ulimit, or overcommit settings may block allocations even when free RAM exists.
.
Yes. Work_mem is per sort or hash node per backend. Setting it too high for all sessions can over-allocate RAM. Raise it only for targeted sessions or queries.
No. PostgreSQL performance collapses under swap, and Linux may invoke the OOM killer. Keep active data in RAM.
Galaxy highlights error codes inline, shows the exact query plan, and suggests memory parameters. Team members can share the failing query link for faster review.
Not directly. Shared_buffers caches table pages, but 53200 relates to per-operation memory like work_mem. Tune each setting separately.
.avif)
.avif){kind=logo}
