Timeouts

Postgres has four timeouts that matter to an application. CapyDB sets exactly one of them for you, because it is the only one where a sensible default exists that cannot break correct code.

What your cell is set to

The default only kills sessions that are idle inside a transaction. A query that runs for an hour is never affected by it; a session that ran BEGIN, did one SELECT, and then went to lunch is.

Setting the rest

Set them per role, not per session. ALTER ROLE writes the setting into the role itself, so it applies to every connection that role opens - including connections borrowed through the pooled endpoint, where a session-level SET would land on whichever server connection you happened to get.

-- Applies to every connection this role opens, on both endpoints.
ALTER ROLE your_role SET statement_timeout = '30s';
ALTER ROLE your_role SET lock_timeout = '10s';

Verify it took:

SELECT rolname, rolconfig FROM pg_roles WHERE rolname = 'your_role';

To scope a timeout to one piece of work instead, use SET LOCAL inside a transaction - it is reverted at commit and is safe on the pooled endpoint:

BEGIN;
SET LOCAL statement_timeout = '5min';   -- this report only
SELECT ...;
COMMIT;

Choosing a statement_timeout

The useful pattern is different limits for different work, which roles give you for free:

-- The web app: nothing should take this long on a request path.
ALTER ROLE app_web SET statement_timeout = '10s';

-- Background workers: batch jobs legitimately run longer.
ALTER ROLE app_worker SET statement_timeout = '5min';

-- Reporting: long by design.
ALTER ROLE app_reports SET statement_timeout = '30min';

Give each of those roles its own connection string and you have separated the workloads without any extra infrastructure. A runaway report can no longer hold a connection that checkout needed.

What a timeout looks like when it fires

57014 and 55P03 cancel the statement and leave the transaction alive but aborted - roll back before issuing anything else. 25P03 terminates the whole connection, so your client's pool needs to reconnect; every mature driver does this automatically.

Retrying a 55P03 after a short randomised delay is usually right. Retrying a 57014 immediately usually is not - the query was too slow once and will be too slow again.