SDB603[medium]Locking
No lock_timeout before a blocking lock
A statement waits for a strong lock on an existing table with no limit on how long it waits.
Why it's risky in PostgreSQL
While a DDL statement waits for its lock (for example behind a long-running query), every new query on that table queues behind it. A migration that's fast once it gets the lock can still stall all traffic while it waits.
Setting lock_timeout makes the migration give up instead, so you can retry it later. ShadowDB reports this once per file, on the first locking statement.
What triggers it, and the safer way
ALTER TABLE orders ADD COLUMN note text;SET lock_timeout = '2s';
ALTER TABLE orders ADD COLUMN note text;Suppress it when you're sure
Put this comment on the line before the statement. The reason is required and shows in the report.
-- shadowdb:allow SDB603 <why this is safe here>Applies to PostgreSQL 14, 15, 16, 17.