Table Lock — DDL Lock

DDL lock: vì sao một ALTER TABLE 50ms vẫn đủ làm sập cả API trong giờ cao điểm DDL trong Postgres không phải "vài lệnh schema chạy nhanh". Hầu hết các form của ALTER TABLE , toàn bộ DROP TABLE , TRUNCATE , REINDEX , CLUSTER , VACUUM FULL , và cả REFRESH MATERIALIZED VIEW (không có CONCURRENTLY ) đều yêu cầu ACCESS EXCLUSIVE — lock mode mạnh nhất, xung đột với mọi mode khác kể cả ACCESS SHARE mà một SELECT thuần đọc cũng cần. Một DDL chạy 50ms vẫn có thể chôn cả service vài phút vì hai thứ Postgres làm theo design: lock được giữ tới hết transaction (không nhả sớm), và lock queue là FIFO — bên đến sau dù mode tương thích vẫn phải đứng sau bên đang đợi. "Migration chạy lúc giờ cao điểm, toàn bộ API treo 5 phút" gần như luôn là class incident này. Cơ chế hoạt động Mỗi lệnh DDL acquire một relation-level lock trên các object nó chạm, theo bảng mode cố định trong Postgres docs mục Explicit Locking . Có ba nhóm cần thuộc: ACCESS EXCLUSIVE — xung đột với mọi mode. Cấp bởi: phần lớn ALTER TABLE (kể cả những form không rewrite data), DROP TABLE , TRUNCATE , REINDEX (non-concurrently), CLUSTER , VACUUM FULL , REFRESH MATERIALIZED VIEW (non-concurrently), LOCK TABLE không kèm mode. Đây là lock "đông cứng" object. SHARE — xung đột với mọi mode ghi ( ROW EXCLUSIVE , SHARE UPDATE EXCLUSIVE , SHARE ROW EXCLUSIVE , EXCLUSIVE , ACCESS EXCLUSIVE ). Cấp bởi: CREATE INDEX (non-concurrently). Cho đọc đi qua, nhưng chặn mọi INSERT / UPDATE / DELETE — trên bảng OLTP nóng đó là downtime ghi. SHARE UPDATE EXCLUSIVE — xung đột với chính nó và các mode mạnh hơn, nhưng không xung đột với ROW EXCLUSIVE . Cấp bởi: CREATE INDEX CONCURRENTLY , REINDEX CONCURRENTLY , VACUUM (không FULL), ANALYZE , ALTER TABLE ... VALIDATE CONSTRAINT , ALTER TABLE ... SET STATISTICS , ALTER INDEX ... RENAME . Đây là mode "online maintenance": cho cả đọc lẫn ghi đi qua, chỉ tự khoá lẫn nhau. Quan trọng: lock giữ tới hết transaction , không có cách nhả sớm. BEGIN; ALTER TABLE ...; <30 phút làm việc khác>; COMMIT; giữ A