statement_timeout and lock_timeout Put a Ceiling on the Damage
statement_timeout cancels a query that runs longer than you allow, lock_timeout gives up when a statement cannot get its lock in time, and idle_in_transaction_session_timeout kills sessions that opened a transaction and wandered off. Setting them per role or per connection means one bad query fails fast and alone instead of piling up behind itself until the pool is empty. They are guard rails, not fixes: the timeout turns a silent outage into a loud, cheap error you can trace.
Questions this Concept answers
Why are these timeouts described as guard rails rather than fixes?
J
jeremy
Video
Zero-Downtime Schema Migrations with Lock Timeouts and Expand-and-Contract in PostgreSQL
In PostgreSQL almost every DDL statement acquires an ACCESS EXCLUSIVE lock, the strictest mode, which conflicts with every other lock including the read lock a plain SELECT takes; because lock reques…