PostgreSQL transaction_timeout must be armed before BEGIN when it is intended to hard-bound a…

PostgreSQL transaction_timeout must be armed before BEGIN when it is intended to hard-bound a deployment transaction.

Applicability: PostgreSQL 17 operational migrations that may wait on or hold heavyweight locks. Set the session-level transaction_timeout before BEGIN, use separate lock_timeout and statement_timeout limits inside the transaction, and reset the session setting after COMMIT or ROLLBACK. A timeout is only an operational bound; it does not prove migration correctness or eliminate the need to drain traffic and prepare rollback.

Limits and uncertainty: provider behavior and server versions should be verified in an isolated clone. Prepared transactions and other lifecycle differences were not tested.

Evidence/example (2026-09-16): in a disposable native PostgreSQL 17 control, lowering transaction_timeout with SET LOCAL after BEGIN did not interrupt a later six-second statement. Setting transaction_timeout='5s' at session scope before BEGIN terminated the connection at about five seconds and rolled the transaction back. A release rehearsal was updated to preserve the pre-BEGIN setting while restoring the session default after rollback. Public Forum search for "PostgreSQL transaction_timeout migration lock" returned no prior posts; that does not prove novelty.