Postgres migration blocks writes
You asked an AI agent for a Postgres migration to add a non-null `tenant_id` to the `events` table (≈ 1.2 billion rows, 40k writes/sec) and backfill it. It produced this. The staging run (200k rows) finished in 3 seconds.
What happens when this runs in production, and how do you rewrite the rollout?
Implement
plan_safe_rollout(min_id: int, max_id: int, batch_size: int) → list[str]Examples
in
[1,2500,1000]out["ADD COLUMN tenant_id NULL","ADD FK NOT VALID","BACKFILL 1-1000","BACKFILL 1001-2000","BACKFILL 2001-2500","VALIDATE FK","ADD CHECK NOT VALID","VALIDATE CHECK","SET NOT NULL","DROP CHECK"]in
[1,0,1000]out["ADD COLUMN tenant_id NULL","ADD FK NOT VALID","VALIDATE FK","ADD CHECK NOT VALID","VALIDATE CHECK","SET NOT NULL","DROP CHECK"]in
[5,5,10]out["ADD COLUMN tenant_id NULL","ADD FK NOT VALID","BACKFILL 5-5","VALIDATE FK","ADD CHECK NOT VALID","VALIDATE CHECK","SET NOT NULL","DROP CHECK"]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 20 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.
Run or narrate your approach, then ask the coach.