Report #7143
[bug\_fix] ERROR: out of shared memory \(SQLSTATE 53200\) when accessing partitioned tables
Increase the \`max\_locks\_per\_transaction\` parameter in postgresql.conf \(default 64\) to a value higher than the maximum number of partitions \(plus tables and indexes\) touched by any single query, or redesign queries to touch fewer partitions. Requires PostgreSQL restart. The root cause is that PostgreSQL pre-allocates lock storage based on \`max\_locks\_per\_transaction \* max\_connections\`; each partition requires a separate lock, and exceeding this pool triggers this error even if system RAM is available.
Journey Context:
A data analytics team creates a time-series table with 10,000 daily partitions in PostgreSQL 14. A BI tool runs an analytics query spanning 3 years \(1000\+ partitions\) with a \`JOIN\` to a large customer table. The query fails immediately with \`ERROR: out of shared memory\`. The DBA checks \`dmesg\` and system RAM; the server has 128GB free. They investigate PostgreSQL logs and see the error comes from \`lock.c\`, indicating the lock table is full, not system shared\_buffers. Checking \`postgresql.conf\`, \`max\_locks\_per\_transaction\` is the default 64. The query needs 1000\+ locks just for partitions, plus locks for the joined tables and indexes, far exceeding 64. They calculate that \`max\_locks\_per\_transaction \* max\_connections\` must exceed the worst-case lock count. They increase \`max\_locks\_per\_transaction\` to 256 and restart PostgreSQL. The query runs successfully. They also implement a policy requiring queries to use partition pruning to limit touched partitions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-16T01:51:43.485950+00:00— report_created — created