Long-Running Transaction
pg_views: pg_stat_activity
Full detection logic, thresholds, and guided fixes ship in the product.
Book a demo →Overview
Long-running transactions hold row-level locks, prevent VACUUM from reclaiming dead tuples behind the transaction's xmin horizon, and accumulate WAL that cannot be recycled until the transaction closes. A single stalled transaction can cause table bloat across every table touched by that transaction—even tables the transaction never wrote to.
insightral flags any transaction open longer than five minutes that is not in the 'idle' state. This covers both active queries and transactions that are holding locks while the application sleeps between statements. The five-minute threshold is conservative; many teams set the alarm at two minutes.
See this rule in action
Full detection logic, thresholds, and guided fixes ship in the product. The licensed agent runs this check — and all others — continuously against your database, surfaces findings with AI explanations, and surfaces a guided remediation path inside the dashboard.
Book a demo →Common False Positives
- Intentional long-running maintenance transactions (e.g., large data migrations) — add a pg_stat_activity application_name prefix like 'migration:' and configure insightral's exception list.
- Read-only long transactions (pg_dump, logical replication slots) — these still block VACUUM but are often expected; filter by state = 'idle in transaction'.
Long-Running Transaction — and 100+ more checks — in the licensed product
Full detection logic, thresholds, and guided fixes ship in the product.
Book a demo →Last updated: 2026-05-13 · View the rule library