本節是PostgreSQL Locks的概要部分,翻譯自README檔案.

### 一、Overview
```
src/backend/storage/lmgr/README

Locking Overview
================

Postgres uses four types of interprocess locks:
PG使用四種型別的鎖:

* Spinlocks.  These are intended for *very* short-term locks.  If a lock
is to be held more than a few dozen instructions, or across any sort of
kernel call (or even a call to a nontrivial subroutine), don't use a
spinlock. Spinlocks are primarily used as infrastructure for lightweight
locks. They are implemented using a hardware atomic-test-and-set
instruction, if available.  Waiting processes busy-loop until they can
get the lock. There is no provision for deadlock detection, automatic
release on error, or any other nicety.  There is a timeout if the lock
cannot be gotten after a minute or so (which is approximately forever in
comparison to the intended lock hold time, so this is certainly an error
condition).
* Spinlocks(自旋鎖).這種一種非常短期的鎖.如果持有鎖會超過幾十個指令週期,或者
  跨越多個型別的核心呼叫,那麼不要使用自旋鎖.
  如可用的話(部分平臺並不可用),Spinlocks主要用於輕量級鎖的基礎"設施".
  等待程式會一直等待直至獲取到鎖(等待1分鐘則超時).沒有提供死鎖檢測/錯誤時自動釋放.

* Lightweight locks (LWLocks).  These locks are typically used to
interlock access to datastructures in shared memory.  LWLocks support
both exclusive and shared lock modes (for read/write and read-only
access to a shared object). There is no provision for deadlock
detection, but the LWLock manager will automatically release held
LWLocks during elog() recovery, so it is safe to raise an error while
holding LWLocks.  Obtaining or releasing an LWLock is quite fast (a few
dozen instructions) when there is no contention for the lock.  When a
process has to wait for an LWLock, it blocks on a SysV semaphore so as
to not consume CPU time.  Waiting processes will be granted the lock in
arrival order.  There is no timeout.
* Lightweight locks (輕量級鎖,LWLocks).這些鎖典型的用於保護共享記憶體中的資料結構.
  LWLocks提供了共享和獨佔模式,沒有提供死鎖檢測,但在elog()恢復期間自動釋放持有的鎖,
  因此在持有輕量級鎖時丟擲異常是安全的.
  沒有衝突的情況下,獲取或者釋放輕量級鎖是相當快的(幾十個指令週期).
  如程式從必須等到LWLock,則會阻塞等待SysV訊號量,這樣可以不需要耗費CPU時間.
  等待程式按到達順序授予鎖.LWLocks沒有超時機制.

* Regular locks (a/k/a heavyweight locks).  The regular lock manager
supports a variety of lock modes with table-driven semantics, and it has
full deadlock detection and automatic release at transaction end.
Regular locks should be used for all user-driven lock requests.
* Regular locks (重量級鎖,a/k/a heavyweight locks). 
  常規的鎖管理支援多種表驅動語義上的鎖模式,有完善的死鎖檢測機制並在事務結束時自動釋放鎖.
  常規鎖應在所有使用者驅動的鎖請求中使用.

* SIReadLock predicate locks.  See separate README-SSI file for details.
* SIReadLock predicate locks(SIReadLock謂詞鎖).詳情參見README-SSI.

Acquisition of either a spinlock or a lightweight lock causes query
cancel and die() interrupts to be held off until all such locks are
released. No such restriction exists for regular locks, however.  Also
note that we can accept query cancel and die() interrupts while waiting
for a regular lock, but we will not accept them while waiting for
spinlocks or LW locks. It is therefore not a good idea to use LW locks
when the wait time might exceed a few seconds.
自旋鎖/輕量級鎖都會導致取消查詢和die()中斷被延遲,直至釋放鎖.
對於常規鎖就沒有這樣的限制.
同時,要注意在等待常規鎖時可以接受取消查詢和die()中斷,但在等待自旋鎖/輕量級鎖時則不接受.
如果等待時間超過幾十秒,使用LWLocks並不是明智的選擇.

The rest of this README file discusses the regular lock manager in detail.

Lock Data Structures
--------------------
Lock資料結構

Lock methods describe the overall locking behavior.  Currently there are
two lock methods: DEFAULT and USER.
鎖定方法描述了鎖定動作的概覽.目前有兩種鎖定方法:DEFAULT和USER.

Lock modes describe the type of the lock (read/write or shared/exclusive).
In principle, each lock method can have its own set of lock modes with
different conflict rules, but currently DEFAULT and USER methods use
identical lock mode sets. See src/include/storage/lock.h for more details.
(Lock modes are also called lock types in some places in the code and
documentation.)
鎖定模式描述了lock(R/W或共享/獨佔)的型別.
原則上,每一種鎖方法可以有自己的鎖模式集合和不同的衝突原則,但當前的DEFAULT/USER方法
會使用相同的鎖模式集合,詳情參見src/include/storage/lock.h
(鎖模式在程式碼和文件中的某些地方也被稱為鎖型別)

There are two main methods for recording locks in shared memory.  The primary
mechanism uses two main structures: the per-lockable-object LOCK struct, and
the per-lock-and-requestor PROCLOCK struct.  A LOCK object exists for each
lockable object that currently has locks held or requested on it.  A PROCLOCK
struct exists for each backend that is holding or requesting lock(s) on each
LOCK object.
在共享記憶體中儲存鎖資訊有兩種主要的方法.其中一種主要的機制使用兩種結構體:
LOCK:每一個鎖定物件一個,per-lockable-object.儲存每一個鎖定的物件(持有鎖或者等待鎖).
PROCLOCK:每一個鎖和請求者一個,per-lock-and-requestor.儲存每一個持有/請求LOCK物件的後端程式.

There is also a special "fast path" mechanism which backends may use to
record a limited number of locks with very specific characteristics: they must
use the DEFAULT lockmethod; they must represent a lock on a database relation
(not a shared relation), they must be a "weak" lock which is unlikely to
conflict (AccessShareLock, RowShareLock, or RowExclusiveLock); and the system
must be able to quickly verify that no conflicting locks could possibly be
present.  See "Fast Path Locking", below, for more details.
另外,還有一種成為"fast path"的機制,後臺程式可使用非常規特性的用於記錄有限數量的鎖,
這種情況下必須使用DEFAULT鎖方法.它們必須表示資料庫關係(非共享關係)上的鎖,
它們必須是一個不太可能出現衝突的"弱"鎖(AccessShareLock, RowShareLock, or RowExclusiveLock);
系統必須能夠快速的驗證衝突鎖有沒有可能出現.詳細參見下面的"Fast Path Locking".

Each backend also maintains an unshared LOCALLOCK structure for each lockable
object and lock mode that it is currently holding or requesting.  The shared
lock structures only allow a single lock grant to be made per lockable
object/lock mode/backend.  Internally to a backend, however, the same lock may
be requested and perhaps released multiple times in a transaction, and it can
also be held both transactionally and session-wide.  The internal request
counts are held in LOCALLOCK so that the shared data structures need not be
accessed to alter them.
每一個後臺程式同時會維護非共享的LOCALLOCK結構體,該結構體儲存鎖定物件和當前持有/請求的鎖模式.
共享鎖結構體只允許為每個鎖定物件/鎖模式/後臺程式授予一個鎖.
但是,在後臺程式內部,同一個鎖可能在同一個事務中請求和釋放多次,並且可以事務/會話模式持有.
內部請求的計數在LOCALLOCK結構體中儲存以便共享資料結構體在更新時不需要訪問.

```

**LOCK**
```

/*
 * Per-locked-object lock information:
 *
 * tag -- uniquely identifies the object being locked
 * grantMask -- bitmask for all lock types currently granted on this object.
 * waitMask -- bitmask for all lock types currently awaited on this object.
 * procLocks -- list of PROCLOCK objects for this lock.
 * waitProcs -- queue of processes waiting for this lock.
 * requested -- count of each lock type currently requested on the lock
 *      (includes requests already granted!!).
 * nRequested -- total requested locks of all types.
 * granted -- count of each lock type currently granted on the lock.
 * nGranted -- total granted locks of all types.
 *
 * Note: these counts count 1 for each backend.  Internally to a backend,
 * there may be multiple grabs on a particular lock, but this is not reflected
 * into shared memory.
 */
typedef struct LOCK
{
    /* hash key */
    LOCKTAG     tag;            /* unique identifier of lockable object */

/* data */
    LOCKMASK    grantMask;      /* bitmask for lock types already granted */
    LOCKMASK    waitMask;       /* bitmask for lock types awaited */
    SHM_QUEUE   procLocks;      /* list of PROCLOCK objects assoc. with lock */
    PROC_QUEUE  waitProcs;      /* list of PGPROC objects waiting on lock */
    int         requested[MAX_LOCKMODES];   /* counts of requested locks */
    int         nRequested;     /* total of requested[] array */
    int         granted[MAX_LOCKMODES]; /* counts of granted locks */
    int         nGranted;       /* total of granted[] array */
} LOCK;

#define LOCK_LOCKMETHOD(lock) ((LOCKMETHODID) (lock).tag.locktag_lockmethodid)

```

**PROCLOCK**
```

/*
 * We may have several different backends holding or awaiting locks
 * on the same lockable object.  We need to store some per-holder/waiter
 * information for each such holder (or would-be holder).  This is kept in
 * a PROCLOCK struct.
 *
 * PROCLOCKTAG is the key information needed to look up a PROCLOCK item in the
 * proclock hashtable.  A PROCLOCKTAG value uniquely identifies the combination
 * of a lockable object and a holder/waiter for that object.  (We can use
 * pointers here because the PROCLOCKTAG need only be unique for the lifespan
 * of the PROCLOCK, and it will never outlive the lock or the proc.)
 *
 * Internally to a backend, it is possible for the same lock to be held
 * for different purposes: the backend tracks transaction locks separately
 * from session locks.  However, this is not reflected in the shared-memory
 * state: we only track which backend(s) hold the lock.  This is OK since a
 * backend can never block itself.
 *
 * The holdMask field shows the already-granted locks represented by this
 * proclock.  Note that there will be a proclock object, possibly with
 * zero holdMask, for any lock that the process is currently waiting on.
 * Otherwise, proclock objects whose holdMasks are zero are recycled
 * as soon as convenient.
 *
 * releaseMask is workspace for LockReleaseAll(): it shows the locks due
 * to be released during the current call.  This must only be examined or
 * set by the backend owning the PROCLOCK.
 *
 * Each PROCLOCK object is linked into lists for both the associated LOCK
 * object and the owning PGPROC object.  Note that the PROCLOCK is entered
 * into these lists as soon as it is created, even if no lock has yet been
 * granted.  A PGPROC that is waiting for a lock to be granted will also be
 * linked into the lock's waitProcs queue.
 */
typedef struct PROCLOCKTAG
{
    /* NB: we assume this struct contains no padding! */
    LOCK       *myLock;         /* link to per-lockable-object information */
    PGPROC     *myProc;         /* link to PGPROC of owning backend */
} PROCLOCKTAG;

typedef struct PROCLOCK
{
    /* tag */
    PROCLOCKTAG tag;            /* unique identifier of proclock object */

/* data */
    PGPROC     *groupLeader;    /* proc's lock group leader, or proc itself */
    LOCKMASK    holdMask;       /* bitmask for lock types currently held */
    LOCKMASK    releaseMask;    /* bitmask for lock types to be released */
    SHM_QUEUE   lockLink;       /* list link in LOCK's list of proclocks */
    SHM_QUEUE   procLink;       /* list link in PGPROC's list of proclocks */
} PROCLOCK;

#define PROCLOCK_LOCKMETHOD(proclock) \
    LOCK_LOCKMETHOD(*((proclock).tag.myLock))

```

**LOCALLOCK**
```

/*
 * Each backend also maintains a local hash table with information about each
 * lock it is currently interested in.  In particular the local table counts
 * the number of times that lock has been acquired.  This allows multiple
 * requests for the same lock to be executed without additional accesses to
 * shared memory.  We also track the number of lock acquisitions per
 * ResourceOwner, so that we can release just those locks belonging to a
 * particular ResourceOwner.
 *
 * When holding a lock taken "normally", the lock and proclock fields always
 * point to the associated objects in shared memory.  However, if we acquired
 * the lock via the fast-path mechanism, the lock and proclock fields are set
 * to NULL, since there probably aren't any such objects in shared memory.
 * (If the lock later gets promoted to normal representation, we may eventually
 * update our locallock's lock/proclock fields after finding the shared
 * objects.)
 *
 * Caution: a locallock object can be left over from a failed lock acquisition
 * attempt.  In this case its lock/proclock fields are untrustworthy, since
 * the shared lock object is neither held nor awaited, and hence is available
 * to be reclaimed.  If nLocks > 0 then these pointers must either be valid or
 * NULL, but when nLocks == 0 they should be considered garbage.
 */
typedef struct LOCALLOCKTAG
{
    LOCKTAG     lock;           /* identifies the lockable object */
    LOCKMODE    mode;           /* lock mode for this table entry */
} LOCALLOCKTAG;

typedef struct LOCALLOCKOWNER
{
    /*
     * Note: if owner is NULL then the lock is held on behalf of the session;
     * otherwise it is held on behalf of my current transaction.
     *
     * Must use a forward struct reference to avoid circularity.
     */
    struct ResourceOwnerData *owner;
    int64       nLocks;         /* # of times held by this owner */
} LOCALLOCKOWNER;

typedef struct LOCALLOCK
{
    /* tag */
    LOCALLOCKTAG tag;           /* unique identifier of locallock entry */

/* data */
    uint32      hashcode;       /* copy of LOCKTAG's hash value */
    LOCK       *lock;           /* associated LOCK object, if any */
    PROCLOCK   *proclock;       /* associated PROCLOCK object, if any */
    int64       nLocks;         /* total number of times lock is held */
    int         numLockOwners;  /* # of relevant ResourceOwners */
    int         maxLockOwners;  /* allocated size of array */
    LOCALLOCKOWNER *lockOwners; /* dynamically resizable array */
    bool        holdsStrongLockCount;   /* bumped FastPathStrongRelationLocks */
    bool        lockCleared;    /* we read all sinval msgs for lock */
} LOCALLOCK;

#define LOCALLOCK_LOCKMETHOD(llock) ((llock).tag.lock.locktag_lockmethodid)

```

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

PostgreSQL 原始碼解讀（219）- Locks(Overview)

相關文章