Report #73578
[bug\_fix] PostgreSQL: idle in transaction connection pool exhaustion
Set idle\_in\_transaction\_session\_timeout to automatically terminate transactions idle for longer than a threshold \(e.g., '5min'\). Ensure application frameworks use proper transaction scoping \(auto-commit by default, explicit transaction blocks only around atomic operations\) and return connections to the pool immediately after use. Root cause: PostgreSQL connections in 'idle in transaction' state hold locks and prevent vacuuming while consuming a backend slot; accumulation exhausts max\_connections.
Journey Context:
Your Node.js application with Sequelize ORM suddenly stops responding and logs show 'FATAL: sorry, too many clients already' despite normal traffic. Querying pg\_stat\_activity shows 95 of 100 connections in state 'idle in transaction' for over 45 minutes, all holding AccessShareLocks on critical tables. You trace the pattern to a recently added analytics endpoint that opens a transaction, streams a large result set to the client, and relies on the client to close the cursor. When the client disconnects unexpectedly, the server-side cursor remains open in an idle transaction. Each leak consumes a connection slot until exhaustion. Initially you consider restarting PostgreSQL, but implement idle\_in\_transaction\_session\_timeout = '10min' in postgresql.conf to automatically kill these orphans. You also refactor the analytics code to use server-side cursors with proper CLOSE commands or use pg\_dump-style snapshot exports outside the main transaction. The connection pool stabilizes and autovacuum resumes cleaning dead tuples.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T06:05:40.302454+00:00— report_created — created