Lock Manager — Lock Overview

Lock trong Postgres: hai tầng heavyweight/lightweight, vì sao một ALTER đứng yên kéo theo cả service Postgres chia khoá thành hai tầng chạy song song. Heavyweight lock (Postgres docs gọi là "regular locks" hay table-level/row-level lock) giữ vai trò bảo vệ object logic — relation, tuple, transactionid — sống suốt một transaction, hiện ra trong view pg_locks và là loại mà application code "thấy" được. Lightweight lock (LWLock) bảo vệ các vùng nhớ chia sẻ bên trong server — buffer descriptor, WAL insert position, hash table của chính lock manager — chỉ ôm trong thời gian rất ngắn, không hiện trong pg_locks nhưng lộ ra qua wait_event_type = 'LWLock' ở pg_stat_activity . Hai tầng có hai cơ chế chờ khác nhau, hai loại sự cố production khác nhau, và nếu chỉ "biết row lock" thì sẽ bỏ qua hai class incident kinh điển: một ALTER TABLE đứng đợi ACCESS EXCLUSIVE làm đông cứng mọi SELECT đến sau nó, và LockManager partition LWLock thành điểm nghẽn khi đụng nhiều partition trong một query. Cơ chế hoạt động Heavyweight lock được quản lý bằng một hash table trong shared memory, chia thành nhiều partition để giảm contention (số partition là NUM_LOCK_PARTITIONS , set tại compile time). Mỗi entry ứng với một (locktag, mode) ; locktag là tuple (locktype, database, relation, ...) nhận diện object cần khoá. Tám lock mode trên relation chia thành ma trận xung đột cố định: ACCESS SHARE (cấp bởi SELECT ) xung đột duy nhất với ACCESS EXCLUSIVE (cấp bởi DROP TABLE , TRUNCATE , hầu hết ALTER TABLE , REINDEX , CLUSTER ); ROW EXCLUSIVE (cấp bởi INSERT / UPDATE / DELETE ) xung đột với SHARE trở lên; SHARE UPDATE EXCLUSIVE (cấp bởi VACUUM không-FULL, ANALYZE , CREATE INDEX CONCURRENTLY ) tự xung đột với chính nó — đó là lý do chỉ một autovacuum hoặc một CREATE INDEX CONCURRENTLY chạy mỗi lần trên cùng bảng. Ma trận này nằm trong docs Postgres mục Explicit Locking và là kiến thức nền cho mọi quyết định migration online. -- xem mode đang giữ trên một bảng SELECT pid , mode , granted , locktype , re