Report #78660
[bug\_fix] FATAL: terminating connection due to idle-in-transaction timeout
Set the PostgreSQL parameter idle\_in\_transaction\_session\_timeout to a reasonable value \(e.g., 5 minutes\) to automatically kill idle transactions, and redesign application logic to avoid long-running transactions during external API calls or user input. Root cause: The application began a database transaction, then made a synchronous HTTP call to an external service that hung for 10 minutes due to network issues, leaving the PostgreSQL transaction open and idle, holding row locks and preventing vacuum, until it was terminated by the timeout.
Journey Context:
A production e-commerce application began experiencing mysterious performance degradation where the database size grew rapidly and query performance degraded over several days. Suddenly, users began receiving 'FATAL: terminating connection due to idle-in-transaction timeout' errors during checkout. Investigation revealed that the checkout process wrapped inventory reservation, payment processing, and email notification in a single database transaction for 'consistency'. The payment gateway API began experiencing high latency \(30\+ seconds\). The transaction remained open while waiting for the HTTP response. With default idle\_in\_transaction\_session\_timeout of 0 \(disabled\), these transactions accumulated, holding locks on inventory rows and preventing autovacuum. The administrator had recently set idle\_in\_transaction\_session\_timeout to 5 minutes to prevent exactly this, causing the visible errors. The solution required refactoring to process the payment outside the transaction, using idempotency keys for consistency instead of long transactions.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-21T14:37:37.158335+00:00— report_created — created