共计 6867 个字符，预计需要花费 18 分钟才能阅读完成。
这篇文章主要讲解了“怎么理解 PostgreSQL Locks 中的 Fast Path Locking”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着丸趣 TV 小编的思路慢慢深入，一起来研究和学习“怎么理解 PostgreSQL Locks 中的 Fast Path Locking”吧！
PG 提供的系统表 pg_locks 中有一个字段:fastpath, 用以表示是否 fastpath, 那 fastpath 指的是什么呢?
一、Fast Path Locking
Fast Path Locking
-----------------
Fast path locking is a special purpose mechanism designed to reduce the
overhead of taking and releasing certain types of locks which are taken
and released very frequently but rarely conflict. Currently, this includes
two categories of locks:
Fast path locking 用以减少那些需要经常获取和释放但又很少出现冲突的锁类型的获取 / 释放负载.
当前的做法, 包括 2 种类型 (category) 的锁:
(1) Weak relation locks. SELECT, INSERT, UPDATE, and DELETE must acquire a
lock on every relation they operate on, as well as various system catalogs
that can be used internally. Many DML operations can proceed in parallel
against the same table at the same time; only DDL operations such as
CLUSTER, ALTER TABLE, or DROP -- or explicit user action such as LOCK TABLE
-- will create lock conflicts with the weak locks (AccessShareLock,
RowShareLock, RowExclusiveLock) acquired by DML operations.
(1)弱关系锁.SELECT,INSERT,UPDATE 和 DELETE 必须在 relation 上获取锁,
这些 relation 是在内部使用的各种系统目录(数据字典).
许多 DML 操作可同一时间在同一个表上进行并行操作; 只有 DDL 操作, 比如 CLUSTER,ALTER TABLE,DROP
或显示的用户操作如 LOCK TABLE 会与需要通过 DML 操作而获得的 weak 锁(AccessShareLock,
RowShareLock, RowExclusiveLock)出现冲突.
(2) VXID locks. Every transaction takes a lock on its own virtual
transaction ID. Currently, the only operations that wait for these locks
are CREATE INDEX CONCURRENTLY and Hot Standby (in the case of a conflict),
so most VXID locks are taken and released by the owner without anyone else
needing to care.
(2)VXID 锁. 每一个事务都会持有自身虚拟事务 ID 锁. 当前的做法是, 等待这些锁的操作只有
CREATE INDEX CONCURRENTLY 和 Hot Standby(出现冲突的情况), 因此大多数 VXID 锁
跟其他进程无关.
The primary locking mechanism does not cope well with this workload. Even
though the lock manager locks are partitioned, the locktag for any given
relation still falls in one, and only one, partition. Thus, if many short
queries are accessing the same relation, the lock manager partition lock for
that partition becomes a contention bottleneck. This effect is measurable
even on 2-core servers, and becomes very pronounced as core count increases.
主要的锁定机制不能很好的处理这种工作负载. 就算锁管理器的 locks 已分区, 对于任意给定的 realtion
仍会落在其中一个且唯一一个分区上. 因此, 如果许多端查询正在访问相同的 relation, 该分区上的锁
会成为争用瓶颈. 随着 CPU 核数的升高, 这种影响会非常明显.
To alleviate this bottleneck, beginning in PostgreSQL 9.2, each backend is
permitted to record a limited number of locks on unshared relations in an
array within its PGPROC structure, rather than using the primary lock table.
This mechanism can only be used when the locker can verify that no conflicting
locks exist at the time of taking the lock.
为了消除这样的瓶颈, 在 PG 9.2 开始, 允许每一个后台进程记录非共享 relation 上有限数目的锁在
PGPROC 结构体中的数组中, 而不是使用主要 lock table. 该机制只用于在锁定者可以验证没有冲突的情况.
A key point of this algorithm is that it must be possible to verify the
absence of possibly conflicting locks without fighting over a shared LWLock or
spinlock. Otherwise, this effort would simply move the contention bottleneck
from one place to another. We accomplish this using an array of 1024 integer
counters, which are in effect a 1024-way partitioning of the lock space.
Each counter records the number of strong locks (that is, ShareLock,
ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock) on unshared
relations that fall into that partition. When this counter is non-zero, the
fast path mechanism may not be used to take new relation locks within that
partition. A strong locker bumps the counter and then scans each per-backend
array for matching fast-path locks; any which are found must be transferred to
the primary lock table before attempting to acquire the lock, to ensure proper
lock conflict and deadlock detection.
该算法的一个关键点是可以验证可能的冲突不会出现, 而不需要与共享 LWLock 或 spinlock 竞争.
否则的话, 这样的处理结果会简单的把争用瓶颈从一个地方移到了另外一个地方.
我们使用 1024 个整型计数器数组对应 1024 个锁空间分区来实现这一点. 每一个计数器记录锁分区上
非共享 relation 上 strong 锁 (ShareLock,ShareRowExclusiveLock, ExclusiveLock, and AccessExclusiveLock) 的数目.
如果该计数器非 0, 则不使用 fast path 机制.
strong 锁会修改计数器, 然后扫描每一个后台进程匹配的 fast-path locks 数组; 每一个匹配的都必须
在尝试获取 lock 前转换为主 lock table, 用以确保正使用确的锁冲突和死锁检测.
On an SMP system, we must guarantee proper memory synchronization. Here we
rely on the fact that LWLock acquisition acts as a memory sequence point: if
A performs a store, A and B both acquire an LWLock in either order, and B
then performs a load on the same memory location, it is guaranteed to see
A s store. In this case, each backend s fast-path lock queue is protected
by an LWLock. A backend wishing to acquire a fast-path lock grabs this
LWLock before examining FastPathStrongRelationLocks to check for the presence
of a conflicting strong lock. And the backend attempting to acquire a strong
lock, because it must transfer any matching weak locks taken via the fast-path
mechanism to the shared lock table, will acquire every LWLock protecting a
backend fast-path queue in turn. So, if we examine
FastPathStrongRelationLocks and see a zero, then either the value is truly
zero, or if it is a stale value, the strong locker has yet to acquire the
per-backend LWLock we now hold (or, indeed, even the first per-backend LWLock)
and will notice any weak lock we take when it does.
在 SMP 系统上, 必须确保正确的内存同步. 在这里, 需要依赖于 LWLock 获取作为内存序列点这一事实:
如果 A 执行 store,A 和 B 按任意顺序获取 LWLock, 然后 B 在相同的内存上执行 load, 这可以确保 A store.
在这种情况下, 每一个后台进程的 fast-path 锁会在检查 FastPathStrongRelationLocks 是否与 strong lock
存在冲突前获取此 LWLock. 后台进程试图获取 strong lock, 因为它必须传输通过 fast-path 路径获取的
匹配 weak locks 到共享 lock table 中, 因此将依次获取保护后台进程 fast-path 的每个 LWLock.
因此, 如果检查 FastPathStrongRelationLocks 结果为 0, 那么该值实际真的为 0 或者是一个固定值,
strong locks 必须请求持有的 per-backend LWLock, 在完成后会关注所有的 weak lock.
Fast-path VXID locks do not use the FastPathStrongRelationLocks table. The
first lock taken on a VXID is always the ExclusiveLock taken by its owner.
Any subsequent lockers are share lockers waiting for the VXID to terminate.
Indeed, the only reason VXID locks use the lock manager at all (rather than
waiting for the VXID to terminate via some other method) is for deadlock
detection. Thus, the initial VXID lock can *always* be taken via the fast
path without checking for conflicts. Any subsequent locker must check
whether the lock has been transferred to the main lock table, and if not,
do so. The backend owning the VXID must be careful to clean up any entry
made in the main lock table at end of transaction.
Fast-path VXID 锁没有使用 FastPathStrongRelationLocks 表.
在 VXID 上获取的第一个锁通常是其自身的 ExclusiveLock. 接下来的 lockers 是等待 VXID 结束的共享 lockers.
实际上,VXID 锁只有使用锁管理器的唯一理由是用于死锁检测. 因此,VXID 的初始化不需要检查冲突
而是直接通过 fast-path 获取. 所有后续的 locker 必须检查锁释放已传输到主 lock table 中, 如没有, 则执行此操作.
拥有 VXID 的后台进程必须在事务结束后小心清理主 lock table 中的 entry.
Deadlock detection does not need to examine the fast-path data structures,
because any lock that could possibly be involved in a deadlock must have
been transferred to the main tables beforehand.
死锁检查不需要检查 fast-path 数据结构, 因为所有的锁已传输到 main table 中.感谢各位的阅读，以上就是“怎么理解 PostgreSQL Locks 中的 Fast Path Locking”的内容了，经过本文的学习后，相信大家对怎么理解 PostgreSQL Locks 中的 Fast Path Locking 这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是丸趣 TV，丸趣 TV 小编将为大家推送更多相关知识点的文章，欢迎关注！
正文完
