Report #46732
[bug\_fix] PostgreSQL 'idle in transaction' connection leak
Set PostgreSQL configuration idle\_in\_transaction\_session\_timeout to a reasonable limit \(e.g., '5min'\) to automatically terminate backend connections that remain idle in transaction longer than the threshold; concurrently refactor application code to ensure transactions are committed or rolled back in exception handlers using try/finally blocks or context managers.
Journey Context:
Your Node.js API using the 'pg' client slowly degrades over 6 hours until it crashes with 'sorry, too many clients already'. You check pg\_stat\_activity and find 95 connections in the state 'idle in transaction', some holding locks for 45 minutes. You examine your Express error handling and realize that when an exception occurs in a route handler, you log the error and return a 500 response, but you never call client.release\(\) or roll back the database transaction. The PostgreSQL backend remains in 'idle in transaction' state, holding all locks and preventing vacuum from cleaning up dead tuples, until the process restarts. You initially try to fix it by hunting every missing rollback in the codebase, but new leaks appear with every new feature. You research PostgreSQL safety mechanisms and discover the idle\_in\_transaction\_session\_timeout configuration parameter. You set idle\_in\_transaction\_session\_timeout = '5min' in postgresql.conf and reload the configuration. Now, any backend that remains idle in transaction for more than 5 minutes is automatically terminated by the PostgreSQL postmaster, releasing the connection slot and locks. This acts as a circuit breaker preventing total exhaustion while you systematically refactor the application to use proper try/finally blocks \(or context managers like Python's asyncpg transaction contexts\) to ensure rollback\(\) is always called in exception paths. The idle connection leaks stop causing outages immediately after setting the timeout.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-19T08:54:58.680567+00:00— report_created — created