本節是PostgreSQL Locks中的Lock Manager Internal Locking部分,翻譯自README檔案.

### 一、Lock Manager Internal Locking
```
Lock Manager Internal Locking
-----------------------------
內部鎖機制

Before PostgreSQL 8.2, all of the shared-memory data structures used by
the lock manager were protected by a single LWLock, the LockMgrLock;
any operation involving these data structures had to exclusively lock
LockMgrLock.  Not too surprisingly, this became a contention bottleneck.
To reduce contention, the lock manager's data structures have been split
into multiple "partitions", each protected by an independent LWLock.
Most operations only need to lock the single partition they are working in.
Here are the details:
在PG 8.2或更舊的版本中,共享快取中的資料結構透過一個單一的LWLock(LockMgrLock)保護;
涉及這些資料結構的所有操作必須持有LockMgrLock獨佔鎖.不用說太多,這會成為爭用的瓶頸.
為了減少爭用,鎖管理器資料結構已拆分為多個"partitions",每一個分割槽使用獨立的LWLock保護.
大多數操作只需要鎖定其中一個分割槽,下面是實現細節:

* Each possible lock is assigned to one partition according to a hash of
its LOCKTAG value.  The partition's LWLock is considered to protect all the
LOCK objects of that partition as well as their subsidiary PROCLOCKs.
* 只需要授予屬於LOCKTAG雜湊值的某個分割槽的鎖,分割槽的LWLock用於保護該分割槽的所有LOCK物件.

* The shared-memory hash tables for LOCKs and PROCLOCKs are organized
so that different partitions use different hash chains, and thus there
is no conflict in working with objects in different partitions.  This
is supported directly by dynahash.c's "partitioned table" mechanism
for the LOCK table: we need only ensure that the partition number is
taken from the low-order bits of the dynahash hash value for the LOCKTAG.
To make it work for PROCLOCKs, we have to ensure that a PROCLOCK's hash
value has the same low-order bits as its associated LOCK.  This requires
a specialized hash function (see proclock_hash).
LOCKs和PROCLOCKs被組織為儲存在共享記憶體中雜湊表以便不同的分割槽使用不同的雜湊鏈,
這樣不同分割槽中的物件就不會出現衝突,透過dynahash.c's "partitioned table"機制實現.
只需要確保分割槽號從LOCKTAG的dynahash雜湊值的低位中獲取即可.
對於PROCLOCKs,必須確保PROCLOCK的雜湊值有與LOCK有相同的低位.這需要特別的雜湊函式(proclock_hash)

* Formerly, each PGPROC had a single list of PROCLOCKs belonging to it.
This has now been split into per-partition lists, so that access to a
particular PROCLOCK list can be protected by the associated partition's
LWLock.  (This rule allows one backend to manipulate another backend's
PROCLOCK lists, which was not originally necessary but is now required in
connection with fast-path locking; see below.)
以前的做法,每一個PGPROC都有一個單獨的PROCLOCKs連結串列.現在已拆分為每一個分割槽一個連結串列,
這樣的好處是訪問一個PROCLOCK連結串列可透過相關的分割槽LWLock保護.
(這個規則允許一個後臺程式可管理另外一個後臺程式的PROCLOCK連結串列,這個事情本來是不需要做的,
但現在在使用fast-path鎖的連線時需要)

* The other lock-related fields of a PGPROC are only interesting when
the PGPROC is waiting for a lock, so we consider that they are protected
by the partition LWLock of the awaited lock.
PGPROC中與鎖相關的域只在PRPROC等待鎖才會變得有用,因此我們考慮透過分割槽LWLOCK中awaited lock來進行保護.

For normal lock acquisition and release, it is sufficient to lock the
partition containing the desired lock.  Deadlock checking needs to touch
multiple partitions in general; for simplicity, we just make it lock all
the partitions in partition-number order.  (To prevent LWLock deadlock,
we establish the rule that any backend needing to lock more than one
partition at once must lock them in partition-number order.)  It's
possible that deadlock checking could be done without touching every
partition in typical cases, but since in a properly functioning system
deadlock checking should not occur often enough to be performance-critical,
trying to make this work does not seem a productive use of effort.
對於普通的鎖請求和釋放,鎖定包含目標鎖的分割槽就已經足夠了.
通常來說,死鎖檢測需要訪問多個分割槽.簡單來說,我們只要按分割槽順序鎖定相關的所有分割槽即可.
(為了避免LWLock死鎖,設定的規則是所有需要鎖定一個以上分割槽的後臺程式必須一次過按順序所有所有分割槽)
在典型情況下,不需要訪問每一個分割槽進行死鎖檢測是可以做到的,但因為在一個正常執行的系統中,
死鎖檢測不應經常發生,因此不會對效能造成較大的影響.

A backend's internal LOCALLOCK hash table is not partitioned.  We do store
a copy of the locktag hash code in LOCALLOCK table entries, from which the
partition number can be computed, but this is a straight speed-for-space
tradeoff: we could instead recalculate the partition number from the LOCKTAG
when needed.
後臺程式的內部LOCALLOCK雜湊表沒有分割槽.
我們確實在LOCALLOCK表條目中儲存了locktag雜湊值的副本,分割槽號可以計算,這是一個以空間換時間的考量:
我們可以從LOCKTAG重新計算分割槽號.

```

### 二、參考資料
[README](https://github.com/postgres/postgres/blob/master/src/backend/storage/lmgr/README)

PostgreSQL 原始碼解讀（222）- Locks(Lock Manager Internal Locking)

相關文章