Write skew là anomaly trong đó hai transaction đọc cùng một tập dữ liệu, mỗi bên kiểm tra thấy điều kiện nghiệp vụ vẫn thoả, rồi mỗi bên ghi vào hàng khác nhau — kết quả là điều kiện đó bị vi phạm dù không hàng nào bị ghi đè.
Ví dụ kinh điển — lịch trực yêu cầu luôn còn ít nhất một bác sĩ:
-- T1 (bác sĩ A xin nghỉ) -- T2 (bác sĩ B xin nghỉ), chạy đồng thời
SELECT count(*) FROM oncall SELECT count(*) FROM oncall
WHERE on_duty = true; -- 2 WHERE on_duty = true; -- 2
-- thấy còn 2 người, hợp lệ -- cũng thấy còn 2 người, hợp lệ
UPDATE oncall SET on_duty = false UPDATE oncall SET on_duty = false
WHERE name = 'A'; WHERE name = 'B';
COMMIT; COMMIT; -- không còn ai trựcVì sao snapshot isolation không cứu được: hai transaction ghi hai hàng khác nhau nên không có xung đột ghi–ghi để phát hiện. Điều bị phá vỡ là tiền đề đọc của mỗi bên, không phải giá trị bị đè.
Chỉ SERIALIZABLE chặn được. PostgreSQL dùng SSI (Serializable Snapshot Isolation): theo dõi quan hệ phụ thuộc đọc–ghi giữa các transaction, phát hiện chu trình nguy hiểm và huỷ một bên bằng lỗi 40001.
Chi phí: phải theo dõi vết đọc nên tốn bộ nhớ và có thể sinh false positive — huỷ cả những transaction thực ra vô hại; tranh chấp càng cao thì tỷ lệ huỷ và retry càng nhiều. Vì vậy SERIALIZABLE chỉ nên bật cho những luồng thật sự cần bất biến toàn cục; phần còn lại dùng SELECT ... FOR UPDATE trên hàng chốt hoặc chuyển bất biến thành ràng buộc trong database.