Report #71308
[bug\_fix] PostgreSQL out of shared memory when increasing max\_connections \(SQLSTATE 53200\)
The root cause is that PostgreSQL pre-allocates shared memory for lock management based on max\_locks\_per\_transaction and max\_connections. When max\_connections is increased significantly without increasing max\_locks\_per\_transaction or shared\_buffers, the lock table exhausts shared memory. The fix is to increase max\_locks\_per\_transaction \(default 64\) proportionally to max\_connections, or better, use a connection pooler to keep max\_connections modest while serving more clients. Requires PostgreSQL restart.
Journey Context:
To handle a traffic spike, a DBA increases PostgreSQL's max\_connections from 100 to 1000 in postgresql.conf and restarts. Shortly after, applications start reporting 'ERROR: out of shared memory' with SQLSTATE 53200 when trying to acquire locks on tables. Checking the logs shows 'out of shared memory' during a simple SELECT ... FOR UPDATE. The DBA initially thinks shared\_buffers is too small and increases it, but the error persists. Digging into PostgreSQL documentation on lock management reveals that shared memory for the lock table is calculated as max\_locks\_per\_transaction × max\_connections. With default max\_locks\_per\_transaction=64 and max\_connections=1000, the lock table tries to allocate 64,000 lock slots, exhausting the shared memory segment. The fix is to increase max\_locks\_per\_transaction to 128 or 256 \(requiring another restart\) or, recognizing that 1000 direct connections is inefficient, revert max\_connections to 200 and implement PgBouncer to handle the 1000 concurrent application requests efficiently without exhausting lock memory.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T02:16:19.258325+00:00— report_created — created