硬核内容: PostgreSQL fast-path lock 分析

硬核内容: PostgreSQL fast-path lock 分析

PG 19 引入了 pg_stat_lock 视图, 用于统计锁等待增量信息, 其中有一项 fastpath_exceeded 指标, 这个指标，值得单独讲一下，因为它不是“锁冲突次数”，而是“锁获取路径退化次数”。

先说结论： 它升高，不等于一定发生了锁等待；但它往往意味着你的锁管理成本在变贵。

什么是 fast-path lock

PostgreSQL 为一部分常见、低冲突的锁设计了 fast-path 快速路径。 核心目标只有一个：别什么锁都进主锁表。

因为主锁表是共享结构，访问它要付出更高的并发协调成本。 如果某些锁本来就很常见、冲突概率又低，那就没必要每次都走“重路径”。

所以 fast-path 本质上是一种优化机制： 能在 backend 自身的 fast-path 槽位里解决，就尽量别进全局主锁表。

fastpath_exceeded 统计的到底是什么

它统计的是：

某类锁本来尝试走 fast-path，但因为 fast-path 槽位容量不够，没走成，只能退回普通路径的次数。

注意两个边界：

• 它不是“锁冲突次数”
• 它也不是“锁等待时长”

它只说明一件事： 快速路径装不下了。

所以这个指标更像“锁子系统的容量压力信号”，而不是“阻塞事故计数器”。

为什么会 exceed

最典型的原因，就是单个事务或单条语句需要同时接触很多对象，导致 fast-path 槽位被打满。

这也是为什么官方测试特意用了“分区表”场景：

1. 建一个分区表
2. 创建超过 max_locks_per_transaction 的大量分区
3. 执行一次会访问这些分区的查询
4. 观察 pg_stat_lock 里 relation 的 fastpath_exceeded 上升

这背后的原理很直接：

• 查询分区表时，执行器往往需要接触多个子分区
• 每个关系对象都可能涉及 relation lock
• 当一个 backend 需要持有的 relation 级锁太多时，fast-path 槽位不够
• 多出来的那部分就只能回退到主锁表

所以它暴露的不是“你被谁堵住了”，而是：

你的 workload 正在把轻量锁路径挤爆。

为什么 DBA 和架构师要重视它

因为 fastpath_exceeded 高，通常意味着这几类风险之一正在发生：

• 分区数过多，单次查询接触对象太多
• 事务过宽，同时持有大量 relation 级锁
• 某些 DDL / 元数据操作让锁对象数急剧膨胀
• 应用访问模式导致 backend 频繁超出 fast-path 容量

这类问题的可怕之处在于： 它不一定马上表现成明显阻塞，但会先表现成锁管理开销上升、并发效率下降、抖动加剧。

也就是说，fastpath_exceeded 更像“事故前兆”，不是“事故现场”。

什么时候它最有解释力

这几个场景里，它特别有价值：

• 大分区表系统
• 多租户 schema 很多、对象很多的系统
• 宽事务、批处理事务
• 一条 SQL 会触达大量分区或大量关系对象的场景
• 并发高但锁等待日志又不明显的系统

如果你发现：

• waits 没有特别夸张
• 但系统并发一高就发抖
• CPU、LWLock、锁相关开销看起来怪怪的
• 同时 relation.fastpath_exceeded 持续增长

那就要警惕了。 问题可能不是“锁冲突严重”，而是“锁路径退化严重”。

它不说明什么

也要防止误判。

fastpath_exceeded 升高，不自动推出以下结论：

• 不代表一定有长时间阻塞
• 不代表一定有死锁风险
• 不代表一定是 SQL 写错了
• 不代表单纯调大 max_locks_per_transaction 就万事大吉

因为如果根因是分区设计过碎、事务范围过宽、访问模式过散，那么调参数只是延后症状，不是消灭原因。

正确的排查思路

看到它升高后，建议按这个顺序想：

1. 是哪类锁升高了 通常重点先看 relation。
2. workload 最近有没有变化 比如新增大量分区、批任务、DDL、复杂报表。
3. 单事务接触对象数是不是过多 尤其是分区表、继承表、复杂查询计划。
4. 是否需要评估 max_locks_per_transaction 但这一步是容量兜底，不是默认答案。
5. 能不能从设计上减少对象接触数 这通常比单纯调参数更根治。

一句话概括

fastpath_exceeded 不是“锁冲突计数器”，而是锁获取从便宜路径退化到昂贵路径的压力指标。 它最适合回答的问题不是“谁阻塞了谁”，而是：

我的并发访问模式，是不是已经把 PostgreSQL 的轻量锁优化打穿了？

下面继续展开讲讲

• fast-path lock 在 PostgreSQL 内部到底是怎么工作的
• fastpath_exceeded 高了以后，DBA 该怎么调参数、改表设计、改 SQL 访问路径

1. fast-path lock 在 PostgreSQL 内部怎么工作

简单说： 它是 PostgreSQL 给一部分常见 relation 锁准备的“快捷通道”。

正常情况下，锁要进全局主锁表；但主锁表是共享结构，并发高时更贵。 所以 PostgreSQL 做了优化：

• 对一部分低冲突、常见的 relation 级锁
• 先尝试放进 backend 自己的 fast-path 槽位
• 放得下，就不走全局主锁表
• 放不下，或者不满足 fast-path 条件，就回退到普通锁路径

所以它的本质是：

• fast-path = 便宜路径
• 普通主锁表 = 更重路径

fastpath_exceeded 变高，表示：

• 本来想走快捷通道
• 但槽位不够
• 只能退回普通路径的次数变多了

它不直接等于锁冲突，但通常意味着锁管理成本上升。

2. fastpath_exceeded 高了以后，DBA 怎么做

先记住原则： 先找“为什么一个事务要碰这么多对象”，再考虑调参数。

优先排查这几类问题：

• 分区太多，一条查询要碰很多分区
• 事务太宽，同时持有很多 relation 锁
• 批处理/报表 SQL 一次扫太多对象
• DDL 频繁，元数据相关锁很多

3. 参数怎么调

最直接的是看 max_locks_per_transaction。

它可以考虑调大，但要谨慎：

• 适合：确实有大量对象需要同时加锁的场景
• 风险：这只是扩容，不是根治；会增加共享内存消耗

所以建议是：

• 如果业务模型合理，只是对象数量确实多，可以适度调大
• 如果根因是设计失控，别指望只靠参数解决

4. 表设计怎么改

重点是减少单次操作接触的对象数。

常见做法：

• 控制分区数量，别把分区切得过碎
• 优化分区策略，让查询更容易分区裁剪
• 避免一个事务跨太多表、分区、索引对象
• 把超大批处理拆小，缩短事务生命周期

一句话： 对象越多，锁越多，fast-path 越容易被打穿。

5. SQL 访问路径怎么改

核心目标也是一个： 让单条 SQL 少碰对象。

可以优先做这些：

• 确保谓词能触发 partition pruning
• 避免无条件扫大量分区
• 把超大查询拆成更小、更聚焦的批次
• 减少一个事务里无必要的多表/多分区访问
• 避免长事务一直占着大量 relation 锁

6. 实战判断标准

如果你看到：

• pg_stat_lock.fastpath_exceeded 持续升高
• 主要集中在 relation
• 同时系统高并发时抖动明显

那优先顺序应该是：

1. 看分区和对象数量
2. 看事务宽度
3. 看 SQL 是否访问过多分区/表
4. 最后再评估 max_locks_per_transaction

一句话总结

• fast-path lock = PostgreSQL 为常见 relation 锁准备的低成本快捷通道
• fastpath_exceeded 高 = 快捷通道容量不够，越来越多锁回退到重路径
• DBA 的正确动作 = 先减对象数、减事务宽度、优化分区裁剪，再考虑调大 max_locks_per_transaction