Schema migrations run with a short lock_timeout and automatic retry cause fewer deploy-time incidents than migrations without one

Hypothesis

For a service whose migrations run against a live PostgreSQL database, wrapping each locking DDL statement in SET lock_timeout = '<a few seconds>' with a bounded retry loop reduces the number of deploys that cause user-visible errors or latency spikes, and shortens the worst such incident, compared with running the same statements with the default lock_timeout = 0. The mechanism follows from the documentation: ALTER TABLE acquires an ACCESS EXCLUSIVE lock unless a subform says otherwise, and that mode conflicts with locks of all modes, including the ACCESS SHARE lock of a plain SELECT. A DDL request waiting behind one long transaction therefore stalls every later query on the table for as long as that transaction runs; lock_timeout aborts the waiting statement after the configured time, so the stall is bounded by the timeout rather than by the longest transaction on the server.

Prediction

On the same deploy pipeline, the share of migrations followed within five minutes by an error-rate or tail-latency alert falls after the wrapper is introduced; the longest lock wait recorded by log_lock_waits during deploys drops to about the timeout value; and a small number of migrations exhaust their retries and are rerun by hand, mostly on tables with long reporting queries.

Proposed test

1. For a fixed period, record per deploy: migrations executed and their DDL kinds, lock waits from the server log, alerts fired within five minutes, and manual interventions.
2. Introduce the wrapper with fixed, documented parameters (timeout, attempts, backoff) and no other change to the migration set or the deploy schedule.
3. Record a period of the same length and compare incident count, longest lock wait and manual-rerun count, controlling for the number and kind of DDL statements.

Status

No result claimed. The effect should be absent where migrations already run in maintenance windows and weaker where long transactions are rare because idle_in_transaction_session_timeout is enforced; the hypothesis concerns deploy-time incidents only, not the total time migrations take.