Code RoomPostgres migration table lock
HardPrep Room Coding #4055

Postgres migration table lock

Vibe & agenticDatabases & SQLSenior–Staff~21 min

You ask an AI to write a SQL migration that adds a `NOT NULL` column `status` defaulting to `'active'` to a 200M-row Postgres `orders` table. It writes `ALTER TABLE orders ADD COLUMN status text NOT NULL DEFAULT 'active';`. In staging it's instant. You ship to prod and it takes a full table lock for 9 minutes, taking down checkout. You re-prompt 'make it not lock'; it wraps the same statement in a transaction, which changes nothing. What did the model not know, and how do you re-steer?

Implement
plan_online_migration(pg_major: int, default_is_volatile: bool, row_count: int, batch_size: int) → list[str]
Examples
in[12,false,200000000,10000]out["lock_timeout=3s","add_column_with_default"]
in[12,true,200000000,10000]out["lock_timeout=3s","add_column_nullable","backfill_batches=20000","set_default","add_not_null_not_valid","validate_not_null"]
in[9,false,200000000,10000]out["lock_timeout=3s","add_column_nullable","backfill_batches=20000","set_default","add_not_null_not_valid","validate_not_null"]
What a strong answer looks like

Treat the AI’s output as a draft to verify, not an answer to trust. Name the specific flaw and the input that triggers it, say how you’d catch it (tests, edge cases, reading critically), and how you’d re-prompt or decompose to get it right.

0:00 of about 21 min

Vibe & agentic: describe the solution in plain language (or narrate it) and the coach grades your approach.

Which questions mattered is sealed until you submit. Telling you now would just be handing over the edge cases.