A lock does not care how many backends are queued behind it. That is the mechanical reason a larger `max_connections` is the wrong first move: the session at the front holds its locks until it commits or rolls back [3], and it is not running a query at all, it is waiting on its client with the transaction still open [5]. New slots are new candidates for the same wait. The slower damage runs in parallel, because old snapshots stay open, VACUUM cannot clean some dead rows, and tables grow [4].
The diagnosis is short and the order is what makes it useful. The first query strips normal idle connections with `state <> 'idle'` [6], leaving sessions that are running queries, waiting, or idle inside a transaction [7]. The worked example shows PID 1596183 active for 00:08:32 [8], and the cheat sheet immediately asks the question that decides the repair: is that query slow, or is it waiting for another session [9]. Same duration, two different fixes. That is where the lock graph belongs, and the article names `pg_blocking_pids()` among the functions it covers [10]; the text supplied to us ends mid-sentence before it demonstrates that function [20], so treat the step as signposted rather than shown.
Then the thresholds, which do not agree with each other. The prose says a transaction open for a few seconds may be normal while 30 minutes or several hours is much more suspicious [12], and it warns against killing every `idle in transaction` connection before you know which application owns it and whether it blocks anyone [13]. The copy-paste cleanup query terminates at five minutes [15]. That is a sixth of the window the same page calls suspicious [19]. The two also read different clocks: the investigation query orders by `xact_start`, defined there as when the transaction started [11], while the sweeper filters `state_change` [15]. If your intent is "this transaction has been open too long", `xact_start` is the column that says so. Keep the `pid <> pg_backend_pid()` condition regardless [15]; it excludes the session running the sweep. Termination itself is well behaved: Postgres closes the session, rolls back the open transaction, and releases the locks [14], which is both the point and the bill, since the transaction's work goes with it.
The cheapest item on the page is `application_name`. Set it per service in the connection string and `pg_stat_activity` shows payment-service sitting in `idle in transaction` next to order-service running active [16]; the author recommends doing this for every service in Go, Node.js and similar setups [17]. Postgres will tell you which service abandoned the transaction, provided you once told it the service's name.
In my context, short transactions behind a pooler, the sweeper stays out of cron and goes in the runbook, keyed on transaction age rather than state age. If your workload legitimately holds a transaction across a user's think time, five minutes is not a threshold you can inherit from someone else's page. Either way the stated goal is the right one: find out why the transaction was left open, not just which PID to kill [18].
