Deadlock — Deadlock Detection
Deadlock detection: vì sao Postgres chỉ dò cycle sau deadlock_timeout , và vì sao retry mù làm vỡ thêm Deadlock xảy ra khi hai (hoặc nhiều) transaction đang giữ lock mà bên kia cần, tạo thành một vòng tròn đợi không thoát ra được nếu không có trọng tài. Postgres là trọng tài đó: nó dựng wait-for graph từ trạng thái lock hiện tại, phát hiện cycle, và chủ động abort một transaction để cắt vòng. Dev gặp class lỗi này không phải vì viết code "sai" mà vì hai code path đụng cùng tài nguyên theo thứ tự khác nhau dưới load cao — ở môi trường dev một mình thì không thấy, lên production concurrent đủ thì ERROR: deadlock detected (SQLSTATE 40P01 ) ném ra, một transaction bị rollback, request user trả 500. Hậu quả nặng nhất không phải bản thân deadlock, mà là retry layer viết kiểu "cứ lỗi thì retry vô hạn": cùng pattern lock sai thứ tự, cùng tạo lại cycle, deadlock counter tăng tuyến tính với traffic, log Postgres ngập, và database CPU bị burn vào việc chạy graph algorithm thay vì việc thật. Cơ chế hoạt động Postgres không dò deadlock liên tục. Mỗi lần một backend phải đợi lock, nó đăng ký với lock manager và đi ngủ; chỉ khi ngủ vượt deadlock_timeout (mặc định 1 giây, GUC ở runtime-config-locks ), backend đó mới được đánh thức để chạy thuật toán dò cycle. Đây là quyết định thiết kế nêu trong Postgres docs về Lock Management: phần lớn lock chờ trong workload bình thường chỉ kéo dài vài ms (chờ một UPDATE ngắn commit) — chạy graph algorithm trên mọi lần lock-wait sẽ tốn CPU vô ích. Lazy detection đánh đổi: nếu có cycle thật, mọi transaction trong cycle treo ít nhất deadlock_timeout trước khi được giải phóng. Khi timer kích hoạt, backend đó dựng wait-for graph từ lock manager: với mỗi process đang đợi lock, vẽ một cạnh hướng từ "process đợi" sang "process giữ lock đó". Postgres còn phải xử lý lock soft-conflict (hai process cùng đợi, không ai giữ — nếu được sắp xếp lại thứ tự thì cả hai đều chạy được mà không cần kill ai); thuật toán thật trong deadlock.c (source tree Postgres) th