Connections
Monitor PostgreSQL connection pool usage in tpaw — active, idle, idle-in-transaction counts, and capacity insights.
The Connections panel shows the current state of all client connections to your PostgreSQL server, along with capacity metrics and automated insights that alert you when connection usage approaches dangerous levels.
Connection summary metrics
| Metric | What it means |
|---|---|
| Total | Total current connections (active + idle + idle in transaction) |
| Max connections | max_connections setting from postgresql.conf |
| Usage % | total / max_connections × 100 |
| Active | Connections currently executing a query |
| Idle | Connections waiting for the next command |
| Idle in transaction | Open transactions that are not actively querying — a common sign of connection leaks |
Connection list
Below the summary, a table lists every current backend connection with:
- PID
- State (with color badge)
- Application name
- Database
- Username
- Connection duration (how long this backend has been connected)
- Last activity time
Automated insights
tpaw analyzes connection metrics and surfaces warnings:
Connection usage at 75%+ (warning)
Connection usage is elevated. Consider reviewing connection pool settings or adding a pooler like PgBouncer.
Connection usage at 90%+ (danger)
Critical: most connections are consumed. New connections may be refused. Increase
max_connectionsor implement connection pooling immediately.
Many idle-in-transaction connections (warning)
Connections stuck in
idle in transactionstate hold locks and consume connection slots. Look for application bugs where transactions are not committed or rolled back.
Refreshing
Click Refresh in the toolbar to reload connection stats. Data is not auto-refreshed to avoid additional load.
Taking action
If you see problematic connections (e.g., long-lived idle-in-transaction):
- Note the PID(s) in question
- Switch to Active Queries panel to terminate them
- Investigate the application creating those connections
For persistent connection exhaustion, consider:
- Using PgBouncer or pgpool-II as a connection pooler
- Reducing
idle_in_transaction_session_timeoutin PostgreSQL config - Reviewing application connection pool settings (min/max pool size, timeout)