A Transaction Left Open Across a Call You Do Not Control
This is the specific defect that turns a slow dependency into a database outage, and it is the payoff of the held-connection and row-lock nodes joined together. The question of what happens between the two short transactions, when the effect succeeded and the confirmation did not, is deliberately not answered here: it belongs to the pipeline Curation's delivery-semantics Concepts and this node links out to them.
Questions this Concept answers
Why does a payment provider slowing from 800 ms to 15 s take down pages that never touch payments at all?
J
jeremy
Text
PostgreSQL Idle in Transaction: Causes and Fixes
An incident write-up on PostgreSQL 'idle in transaction' sessions. It defines the state, then explains the mechanism: the oldest running transaction pins the xmin horizon, so VACUUM cannot reclaim an…