Version: v0.1.44
client_idle_timeout is enforced in frontend/client/mod.rs as a read timeout on the client socket: any client that sends no bytes for the configured duration is disconnected. This is applied uniformly to every client on the proxy — there is no per-user or per-pool override.
This breaks a legitimate and common client class: LISTEN/NOTIFY subscribers. A job-runner that issues LISTEN queue_events and then blocks waiting for notifications sends nothing on the wire by design — silence is its steady state, not idleness in the "abandoned connection" sense. With a global client_idle_timeout of, say, 60s, PgDog kills the listener every 60s of quiet, and the client sees server closed the connection unexpectedly mid-wait. In our production deployment this turned a job-runner's SELECT_TIMEOUT=60s wait loop into ~8,400 disconnect errors/day.
Crucially, nothing server-side can protect such a client: PostgreSQL per-user settings (ALTER ROLE ... SET idle_session_timeout = 0, etc.) govern the server's view of the session, but the disconnect here is performed by PgDog on the frontend socket before the server has any say. The only workarounds are (a) raising the global timeout for all clients, weakening the protection it exists to provide, or (b) making every LISTEN client emit keepalive traffic, which not all drivers/frameworks support cleanly.
Request: allow client_idle_timeout to be overridden per user and/or per pool (e.g. in the [[pools.users]] section), with 0/off meaning exempt. Alternatively (or additionally): automatically exempt clients with active LISTEN registrations from the idle read-timeout, since PgDog already tracks their subscriptions in the pub/sub layer.
Version: v0.1.44
client_idle_timeoutis enforced infrontend/client/mod.rsas a read timeout on the client socket: any client that sends no bytes for the configured duration is disconnected. This is applied uniformly to every client on the proxy — there is no per-user or per-pool override.This breaks a legitimate and common client class: LISTEN/NOTIFY subscribers. A job-runner that issues
LISTEN queue_eventsand then blocks waiting for notifications sends nothing on the wire by design — silence is its steady state, not idleness in the "abandoned connection" sense. With a globalclient_idle_timeoutof, say, 60s, PgDog kills the listener every 60s of quiet, and the client seesserver closed the connection unexpectedlymid-wait. In our production deployment this turned a job-runner'sSELECT_TIMEOUT=60swait loop into ~8,400 disconnect errors/day.Crucially, nothing server-side can protect such a client: PostgreSQL per-user settings (
ALTER ROLE ... SET idle_session_timeout = 0, etc.) govern the server's view of the session, but the disconnect here is performed by PgDog on the frontend socket before the server has any say. The only workarounds are (a) raising the global timeout for all clients, weakening the protection it exists to provide, or (b) making every LISTEN client emit keepalive traffic, which not all drivers/frameworks support cleanly.Request: allow
client_idle_timeoutto be overridden per user and/or per pool (e.g. in the[[pools.users]]section), with0/offmeaning exempt. Alternatively (or additionally): automatically exempt clients with active LISTEN registrations from the idle read-timeout, since PgDog already tracks their subscriptions in the pub/sub layer.