57P05FATALTier 2 — Caution✅ HIGH confidence

idle session timeout

Category: Operator InterventionVersions: Postgres 14+

What this means

SQLSTATE 57P05 is raised when a session has been completely idle (no queries, not inside a transaction) for longer than idle_session_timeout. Postgres terminates the idle session to reclaim resources.

Why it happens

1An application connection has been open but completely idle for longer than idle_session_timeout
2Connection pool idle connections exceeding the session timeout

How to reproduce

Application connection idle beyond idle_session_timeout.

trigger — this will ERROR

-- In postgresql.conf:
-- idle_session_timeout = 5min

FATAL: terminating connection due to idle-session timeout

Fix 1: Configure the connection pool to close connections before the timeout

When a connection pool holds idle connections too long.

fix

Why this works

Set the pool maxIdleTime to less than idle_session_timeout. The pool will close and recreate connections before Postgres terminates them.

Fix 2: Increase idle_session_timeout or disable it for legitimate long-idle scenarios

When idle connections are expected (interactive sessions, monitoring tools).

fix

SET idle_session_timeout = 0; -- disable for this session

Why this works

Setting to 0 disables the timeout for a specific session. Alternatively, increase the value in postgresql.conf for the whole server.

What not to do

✗

Disable idle_session_timeout server-wide

Why it's wrong: Idle connections hold resources (memory, file descriptors). Use connection pooling instead.

Version notes

Postgres 14+idle_session_timeout parameter and SQLSTATE 57P05 introduced in Postgres 14.

Sources

📚 Official docs: https://www.postgresql.org/docs/current/errcodes-appendix.html

📚 Feature docs: https://www.postgresql.org/docs/current/runtime-config-client.html#GUC-IDLE-SESSION-TIMEOUT

🔧 Source ref: Class 57 — Operator Intervention (Postgres-specific)

Confidence assessment

✅ HIGH confidence

Postgres-specific since 14. Stable.