1205 — Lock wait timeout exceeded

MySQL raises error 1205 when a statement waits longer than innodb_lock_wait_timeout for a row lock, rolling back only that statement, so the transaction survives and can retry after the blocker commits.

Reproduce it

Two sessions want the same row. B caps how long it's willing to queue. The -- [A] and -- [B] markers say who runs each statement, top to bottom.

-- [A] lock the row and hold it
BEGIN;
UPDATE accounts SET balance = 200 WHERE id = 1;

-- [B] wait at most one second for that lock, then give up
SET SESSION innodb_lock_wait_timeout = 1;
UPDATE accounts SET balance = 300 WHERE id = 1;

B's update queues behind A's lock for one second, then fails with ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction. Despite the "try restarting transaction" wording, InnoDB rolled back only this one statement by default, so B's transaction is still open: once A commits, B can simply rerun the update. That's the key contrast with a deadlock (1213), which discards the whole transaction and leaves nothing to retry in place.

Run it yourself

The NOWAIT, lock timeouts, SKIP LOCKED lesson renders this scenario as a verified transcript alongside the fail-fast alternatives. For the queue B is waiting in, read Lock queues and Row locks.

The PostgreSQL side

PostgreSQL's equivalent is 55P03, raised when its lock_timeout expires. Same idea, two differences: PostgreSQL's default is no timeout at all (wait forever) rather than InnoDB's 50 seconds, and PostgreSQL reuses that one 55P03 for the NOWAIT fast-fail too, where MySQL splits it out as 3572.