3572 — Statement aborted (NOWAIT)

InnoDB SELECT ... FOR UPDATE NOWAIT can raise 3572 on a conflicting row-lock request; NOWAIT does not remove metadata waits or define every transaction-recovery case.

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's standalone query raises 3572, and the complete Scenario asserts a later successful query after A commits. This rejects the conflicting row-lock request rather than queuing it. Metadata/table-lock waits and other errors are separate; no exact latency is measured. Returning busy or retrying is application advice. A row locked in a compatible mode need not cause this error.

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.