Nhiều database khóa hàng khi đọc để tránh đọc dở dang — PostgreSQL thì không, nhờ MVCC. Bài này đo thật với hai phiên psql đồng thời: khi phiên A UPDATE balance=999 chưa commit, phiên B vẫn đọc được balance=100 (bản cũ) mà không bị chặn. Xem metadata ẩn xmin/xmax/ctid để hiểu vì sao UPDATE tạo phiên bản mới thay vì sửa tại chỗ.
Mức cô lập giao dịch quyết định một giao dịch được thấy gì từ giao dịch khác đang chạy. Bài này đo thật trên pg-lab từng bất thường: ở Read Committed đọc cùng hàng hai lần ra 100 rồi 200 (đọc lặp sai), ở Repeatable Read vẫn 100 (an toàn). Và sự thật ít người biết: PostgreSQL không có đọc bẩn kể cả khi đặt Read Uncommitted.
Hai mức cô lập trông giống nhau cho đến khi có ghi đồng thời. Bài này đo thật trên pg-lab mẫu đọc-tính-ghi kinh điển: ở Read Committed, hai giao dịch cùng +10 cho kết quả 110 thay vì 120 — lost update âm thầm, không báo lỗi. Ở Repeatable Read, PostgreSQL phát hiện và báo could not serialize access, buộc thử lại — và lần thử lại cho đúng 120.
Có một loại bug đồng thời tinh vi hơn lost update: hai giao dịch đọc chung một điều kiện rồi ghi hai hàng khác nhau, phá vỡ một ràng buộc mà không cái nào tự biết. Bài này đo thật trên pg-lab ví dụ hai bác sĩ cùng xin nghỉ: ở Repeatable Read cả hai thành công và còn 0 người trực (sai), ở Serializable một giao dịch bị hủy với lỗi read/write dependencies và ràng buộc được giữ.
MVCC giúp đọc không chặn ghi, nhưng khi cần 'đọc rồi chắc chắn ghi' bạn phải khóa hàng tường minh bằng FOR UPDATE. Bài này đo thật trên pg-lab: phiên thứ hai chờ 2.535 ms cho phiên thứ nhất nhả khóa cùng hàng, quan sát pg_locks và wait_event=Lock/transactionid, và NOWAIT báo lỗi ngay thay vì chờ. Hai view vàng để chẩn đoán treo vì khóa.
Hai giao dịch khóa chéo nhau — A giữ hàng 1 xin hàng 2, B giữ hàng 2 xin hàng 1 — là công thức của deadlock. Bài này tạo deadlock thật trên pg-lab: PostgreSQL tự phát hiện vòng chờ và hủy một nạn nhân với ERROR deadlock detected, giao dịch kia đi tiếp. Và cách tránh triệt để: luôn khóa các hàng theo cùng một thứ tự.