3572 — Statement aborted (NOWAIT)

MySQL raises error 3572 when SELECT ... FOR UPDATE NOWAIT finds the row already locked and refuses to queue, failing instantly instead of waiting, so you can fall back rather than block.

Reproduce it

Two sessions want the same row, but B asks not to wait for it. The -- [A] and -- [B] markers say who runs each statement, top to bottom.

-- [A] lock the row
BEGIN;
SELECT id FROM accounts WHERE id = 1 FOR UPDATE;

-- [B] ask for the same row, but refuse to queue for it
SELECT id FROM accounts WHERE id = 1 FOR UPDATE NOWAIT;

B fails at once, no waiting and no timeout, raising ERROR 3572 (HY000): Statement aborted because lock(s) could not be acquired immediately and NOWAIT is set. That's the whole purpose of NOWAIT: instead of joining the lock queue and blocking, the statement gives up immediately so your code can do something else, whether that's skipping the row, returning "busy," or trying a different one. Once A commits and releases the lock, the same NOWAIT query succeeds.

Run it yourself

The NOWAIT, lock timeouts, SKIP LOCKED lesson renders this scenario as a verified transcript and sets NOWAIT next to SKIP LOCKED and the ordinary lock-wait timeout. For the queue you're stepping out of, read Lock queues.

The PostgreSQL side

PostgreSQL does the same fail-fast, but doesn't give it a dedicated code. SELECT ... FOR UPDATE NOWAIT there raises 55P03, the very same code a lock_timeout expiry uses. MySQL keeps the instant refusal (3572) and the timed-out wait (1205) as separate numbers.