A lock wait can be healthy coordination or an expensive queue. PostgreSQL’s lock_timeout lets an operation stop waiting, but it does not diagnose why the holder is slow or decide whether retrying is appropriate. Choose the timeout from the operation’s latency budget, and inspect the blocking transaction before increasing the limit or multiplying attempts. ...
A distributed lock looks simple, but when a client stalls and wakes late its claim to that lock becomes stale; the fencing token turns that stale claim into a verifiable number. A lock alone is not enough A distributed lock protects a resource from two writers, but it does nothing about a writer that already lost the lock. Network latency can freeze one node mid-write, the lease expires, another leader takes over, and the old leader resumes from the stale frame it still remembers as its permission. This is the classic condition a lock cannot see: the writer no longer holds the token but still believes it does. The result is corruption that looks like two legitimate owners wrote different data, because from the resource’s view both held valid credentials at different instants. Depending only on a hopeful lease expiry leaves a window where the corruption is baked in before anyone notices. ...
An advisory lock lets an application coordinate work using an identifier that need not correspond to a table row. For example, workers can agree that only one connection may refresh a particular report at a time. PostgreSQL manages ownership and contention, while the application defines what the identifier means and which work requires it. ...
A deadlock requires a cycle of incompatible waits. If one transaction holds a row while another waits, the holder can still finish and release it. If both hold a resource the other needs, neither can complete that path. PostgreSQL detects the cycle and aborts one transaction, allowing the other to continue. The application must distinguish that rejection from an ordinary slow wait. ...