跳转到主要内容

这是本节的多页打印视图。 .

返回本页常规视图.

LWLock 等待

PostgreSQL 内部共享内存数据结构上的竞争。

LWLock 表示后端没能立即取得保护内部共享内存结构的轻量级锁。它不是 SQL 行锁或表锁,pg_locks 通常也无法指出它的持有者。

值班规则重复采样 → 锁定一个热点 tranche → 与负载关联

怎样阅读这一类

单张快照里的 LWLock 通常只是调度噪声。只有同一个名称在连续样本中反复出现,并且受影响前台会话的延迟同步上升时,才把它当成竞争。

  • 正常: 生成 WAL、获取快照、查找缓冲区、清理或检查点期间短暂出现。
  • 关注: 连续三张、间隔 1 秒的快照里,同一事件至少占活动前台后端的 10%。
  • 紧急: 至少 25% 的活动前台后端堆在同一事件上,等待持续超过 5 秒,或吞吐同时断崖式下降。

这些百分比是现场分级阈值,不是 PostgreSQL 的保证值。必须与本集群基线比较,并排除本来就应在主循环中等待的后台进程。

值得先认出的十个事件

事件 受保护资源 常见现场
BufferContent 单个共享缓冲区的内容 大量会话访问同一热点页
BufferMapping 缓冲区映射表分区 工作集抖动或大规模并发扫描
LockManager 重量级锁管理器状态 锁数量爆炸、DDL 或锁风暴
ProcArray 共享进程/事务数组 获取快照与事务 ID 压力
WALBufMapping WAL 缓冲区页面映射 写入压力下 WAL buffer 快速换页
WALInsert WAL 插入状态 大量写会话在插入 WAL 时串行化
WALWrite WAL 缓冲区写协调 WAL 写入或刷盘路径跟不上
XactSLRU 事务状态 SLRU pg_xact 缓存抖动或检查很老的可见性
MultiXactMemberSLRU Multixact member SLRU 大量行锁与 multixact 抖动
SyncRep 同步复制等待队列 提交确认与 sender 状态发生竞争

常见误读

  1. “LWLock 说明锁泄漏了。” 不是。它是短暂的内部临界区;持续、重复出现才是信号。
  2. “页面显示的查询就是持有者。” pg_stat_activity.query 属于等待者;持有者可能是走另一条源码路径的后端。
  3. “多加 CPU 就能解决。” 更多并发反而可能加剧共享内存热点。先确认受保护资源与负载形状。
  4. “pg_locks 能找出阻塞者。” 它覆盖重量级锁与谓词锁,不覆盖一般 LWLock 所有权。

页面级热点先看 BufferContent,写入密集集群先看 WALInsert。

1 - LWLock: AddinShmemInit

等待管理扩展在共享内存中的空间分配。
PostgreSQL 等待事件档案
类别LWLock 事件AddinShmemInit 版本PG 13-18 证据3 个源码位置

官方描述译文

等待管理扩展在共享内存中的空间分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:328。探针覆盖的操作是:等待管理扩展在共享内存中的空间分配。LWLockAcquire 无法立即取得显示为 AddinShmemInit 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AddinShmemInit 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AddinShmemInit'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AddinShmemInit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

2 - LWLock: AioUringCompletion

等待另一个进程通过 io_uring 完成 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件AioUringCompletion 版本PG 18 证据3 个源码位置

官方描述译文

等待另一个进程通过 io_uring 完成 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:180。探针覆盖的操作是:等待另一个进程通过 io_uring 完成 I/O。LWLockAcquire 无法立即取得显示为 AioUringCompletion 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AioUringCompletion 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AioUringCompletion'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AioUringCompletion'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

3 - LWLock: AioWorkerSubmissionQueue

等待访问 AIO worker 提交队列。
PostgreSQL 等待事件档案
类别LWLock 事件AioWorkerSubmissionQueue 版本PG 18 证据3 个源码位置

官方描述译文

等待访问 AIO worker 提交队列。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/aio/method_worker.c:253。探针覆盖的操作是:等待访问 AIO worker 提交队列。LWLockAcquire 无法立即取得显示为 AioWorkerSubmissionQueue 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AioWorkerSubmissionQueue 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AioWorkerSubmissionQueue'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AioWorkerSubmissionQueue'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

4 - LWLock: AutoFile

等待更新 postgresql.auto.conf 文件。
PostgreSQL 等待事件档案
类别LWLock 事件AutoFile 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新 postgresql.auto.conf 文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:340。探针覆盖的操作是:等待更新 postgresql.auto.conf 文件。LWLockAcquire 无法立即取得显示为 AutoFile 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AutoFile 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AutoFile'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AutoFile'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

5 - LWLock: Autovacuum

等待读取或更新 autovacuum worker 的当前状态。
PostgreSQL 等待事件档案
类别LWLock 事件Autovacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 autovacuum worker 的当前状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/autovacuum.c:611。探针覆盖的操作是:等待读取或更新 autovacuum worker 的当前状态。LWLockAcquire 无法立即取得显示为 Autovacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/Autovacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'Autovacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'Autovacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

6 - LWLock: AutovacuumSchedule

等待确认被选中进行 autovacuum 的表仍需要 vacuum。
PostgreSQL 等待事件档案
类别LWLock 事件AutovacuumSchedule 版本PG 13-18 证据3 个源码位置

官方描述译文

等待确认被选中进行 autovacuum 的表仍需要 vacuum。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/autovacuum.c:2337。探针覆盖的操作是:等待确认被选中进行 autovacuum 的表仍需要 vacuum。LWLockAcquire 无法立即取得显示为 AutovacuumSchedule 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/AutovacuumSchedule 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'AutovacuumSchedule'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'AutovacuumSchedule'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

7 - LWLock: BackgroundWorker

等待读取或更新后台 worker 的状态。
PostgreSQL 等待事件档案
类别LWLock 事件BackgroundWorker 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新后台 worker 的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/bgworker.c:1070。探针覆盖的操作是:等待读取或更新后台 worker 的状态。LWLockAcquire 无法立即取得显示为 BackgroundWorker 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/BackgroundWorker 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BackgroundWorker'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BackgroundWorker'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

8 - LWLock: BtreeVacuum

等待读取或更新 B-tree 索引中与 vacuum 相关的信息。
PostgreSQL 等待事件档案
类别LWLock 事件BtreeVacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 B-tree 索引中与 vacuum 相关的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/nbtree/nbtutils.c:3519。探针覆盖的操作是:等待读取或更新 B-tree 索引中与 vacuum 相关的信息。LWLockAcquire 无法立即取得显示为 BtreeVacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/BtreeVacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BtreeVacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BtreeVacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

9 - LWLock: BufferContent

等待访问内存中的数据页。
PostgreSQL 等待事件档案
类别LWLock 事件BufferContent 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问内存中的数据页。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

后端已经找到所需的共享缓冲区,但尚未取得该 buffer descriptor 的 content lock。堆表与索引代码在读取或修改内存页前都会取得此锁,因此大量工作进程访问同一页面时会在这里串行化。

正常还是麻烦?

  • 正常: 并发读写共享页面时,零星而短暂的样本很常见。
  • 需要调查: 大量前台会话连续命中时,通常指向热点堆表/索引页、向右增长的索引,或与业务同时访问相同块的维护任务。

诊断 SQL

正在等待 LWLock/BufferContent 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BufferContent'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BufferContent'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 找出等待会话共同访问的关系与语句。
  2. 用页面与索引证据确认热点,不能只凭等待名称下结论。
  3. 先分散热点键、批量写入或错峰维护,再考虑容量调整。

源码证据

典型事故模式

单调递增键让并发 B-tree 插入集中到最右叶子页,BufferContent 与插入延迟同步上升。

10 - LWLock: BufferMapping

等待将数据块关联到 buffer pool 中的 buffer。
PostgreSQL 等待事件档案
类别LWLock 事件BufferMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将数据块关联到 buffer pool 中的 buffer。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

缓冲区管理器把 relation/fork/block 标签哈希到由 BufferMappingLock 保护的分区。查找、插入、淘汰和重新分配标签都会短暂取得该分区锁;大规模并发未命中或缓冲区抖动会增加碰撞。

正常还是麻烦?

  • 正常: 页面进入或离开共享缓冲区时,短暂等待属于正常现象。
  • 需要调查: 持续出现通常意味着工作集反复冲刷 shared buffers、大量并行扫描,或访问集中映射到少数分区。

诊断 SQL

正在等待 LWLock/BufferMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'BufferMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'BufferMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按数据库与语句关联缓冲命中率和读取量。
  2. 检查是否出现新扫描、缓存过小或并发突增。
  3. 先降低并发扫描扇出或修正访问路径,再决定是否扩大 shared_buffers。

源码证据

典型事故模式

执行计划退化引发大量并发大扫描,缓冲映射分区变热,同时有用页面被挤出缓存。

11 - LWLock: Checkpoint

等待开始执行检查点。
PostgreSQL 等待事件档案
类别LWLock 事件Checkpoint 版本PG 13 证据3 个源码位置

官方描述译文

等待开始执行检查点。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ — — — — —

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:765,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/xlog.c:8957。探针覆盖的操作是:等待开始执行检查点。LWLockAcquire 无法立即取得显示为 Checkpoint 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/Checkpoint 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'Checkpoint'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'Checkpoint'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

12 - LWLock: CheckpointerComm

等待管理 fsync 请求。
PostgreSQL 等待事件档案
类别LWLock 事件CheckpointerComm 版本PG 13-18 证据3 个源码位置

官方描述译文

等待管理 fsync 请求。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/checkpointer.c:1164。探针覆盖的操作是:等待管理 fsync 请求。LWLockAcquire 无法立即取得显示为 CheckpointerComm 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CheckpointerComm 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CheckpointerComm'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CheckpointerComm'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

13 - LWLock: CommitTs

等待读取或更新事务提交时间戳的最近设定值。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTs 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新事务提交时间戳的最近设定值。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/commit_ts.c:206。探针覆盖的操作是:等待读取或更新事务提交时间戳的最近设定值。LWLockAcquire 无法立即取得显示为 CommitTs 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTs 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTs'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTs'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

14 - LWLock: CommitTsBuffer

等待事务提交时间戳 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTsBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待事务提交时间戳 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:141。探针覆盖的操作是:等待事务提交时间戳 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 CommitTsBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTsBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTsBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTsBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

15 - LWLock: CommitTsSLRU

等待访问事务提交时间戳 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件CommitTsSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问事务提交时间戳 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:172。探针覆盖的操作是:等待访问事务提交时间戳 SLRU 缓存。LWLockAcquire 无法立即取得显示为 CommitTsSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/CommitTsSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'CommitTsSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'CommitTsSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

16 - LWLock: ControlFile

等待读取或更新 pg_control 文件,或创建新的 WAL 文件。
PostgreSQL 等待事件档案
类别LWLock 事件ControlFile 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_control 文件,或创建新的 WAL 文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/xlog.c:2723。探针覆盖的操作是:等待读取或更新 pg_control 文件,或创建新的 WAL 文件。LWLockAcquire 无法立即取得显示为 ControlFile 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ControlFile 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ControlFile'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ControlFile'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

17 - LWLock: DSMRegistry

等待读取或更新动态共享内存注册表。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistry 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新动态共享内存注册表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/dsm_registry.c:98。探针覆盖的操作是:等待读取或更新动态共享内存注册表。LWLockAcquire 无法立即取得显示为 DSMRegistry 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistry 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistry'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistry'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

18 - LWLock: DSMRegistryDSA

等待访问动态共享内存注册表的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistryDSA 版本PG 17-18 证据3 个源码位置

官方描述译文

等待访问动态共享内存注册表的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:170。探针覆盖的操作是:等待访问动态共享内存注册表的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 DSMRegistryDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistryDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistryDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistryDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

19 - LWLock: DSMRegistryHash

等待访问动态共享内存注册表的共享哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件DSMRegistryHash 版本PG 17-18 证据3 个源码位置

官方描述译文

等待访问动态共享内存注册表的共享哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:171。探针覆盖的操作是:等待访问动态共享内存注册表的共享哈希表。LWLockAcquire 无法立即取得显示为 DSMRegistryHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DSMRegistryHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DSMRegistryHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DSMRegistryHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

20 - LWLock: DynamicSharedMemoryControl

等待读取或更新动态共享内存分配信息。
PostgreSQL 等待事件档案
类别LWLock 事件DynamicSharedMemoryControl 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新动态共享内存分配信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/dsm.c:549。探针覆盖的操作是:等待读取或更新动态共享内存分配信息。LWLockAcquire 无法立即取得显示为 DynamicSharedMemoryControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/DynamicSharedMemoryControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'DynamicSharedMemoryControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'DynamicSharedMemoryControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

21 - LWLock: InjectionPoint

等待读取或更新与注入点相关的信息。
PostgreSQL 等待事件档案
类别LWLock 事件InjectionPoint 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新与注入点相关的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:353。探针覆盖的操作是:等待读取或更新与注入点相关的信息。LWLockAcquire 无法立即取得显示为 InjectionPoint 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/InjectionPoint 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'InjectionPoint'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'InjectionPoint'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

22 - LWLock: LockFastPath

等待读取或更新进程的快速路径锁信息。
PostgreSQL 等待事件档案
类别LWLock 事件LockFastPath 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新进程的快速路径锁信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:151。探针覆盖的操作是:等待读取或更新进程的快速路径锁信息。LWLockAcquire 无法立即取得显示为 LockFastPath 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LockFastPath 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LockFastPath'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LockFastPath'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

23 - LWLock: LockManager

等待读取或更新“重量级”锁的信息。
PostgreSQL 等待事件档案
类别LWLock 事件LockManager 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新“重量级”锁的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

重量级锁的账本存放在由 LockHashPartitionLock 分区保护的共享哈希表中。获取、授予、释放或检查大量重量级锁时,即使不存在 SQL 层锁冲突,也可能在分区锁上竞争。

正常还是麻烦?

  • 正常: 普通关系锁与事务锁流量会带来小规模突发。
  • 需要调查: 持续占比通常来自锁扇出:超大事务、大量分区、频繁 DDL,或成千上万的排队锁请求。

诊断 SQL

正在等待 LWLock/LockManager 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LockManager'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LockManager'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按 PID 统计 pg_locks 行数并检查阻塞树。
  2. 定位一次触碰大量关系或分区的语句。
  3. 缩短事务并降低锁扇出;只有真实容量报错时才提高 max_locks_per_transaction。

源码证据

典型事故模式

发布过程对数千分区执行 DDL,同时业务会话获取关系锁;在明显阻塞者出现前,内部锁表已经发生竞争。

24 - LWLock: LogicalRepLauncherDSA

等待访问逻辑复制 launcher 的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepLauncherDSA 版本PG 16-18 证据3 个源码位置

官方描述译文

等待访问逻辑复制 launcher 的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:168。探针覆盖的操作是:等待访问逻辑复制 launcher 的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 LogicalRepLauncherDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepLauncherDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepLauncherDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepLauncherDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

25 - LWLock: LogicalRepLauncherHash

等待访问逻辑复制 launcher 的共享哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepLauncherHash 版本PG 16-18 证据3 个源码位置

官方描述译文

等待访问逻辑复制 launcher 的共享哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:169。探针覆盖的操作是:等待访问逻辑复制 launcher 的共享哈希表。LWLockAcquire 无法立即取得显示为 LogicalRepLauncherHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepLauncherHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepLauncherHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepLauncherHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

26 - LWLock: LogicalRepWorker

等待读取或更新逻辑复制 worker 的状态。
PostgreSQL 等待事件档案
类别LWLock 事件LogicalRepWorker 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新逻辑复制 worker 的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/launcher.c:189。探针覆盖的操作是:等待读取或更新逻辑复制 worker 的状态。LWLockAcquire 无法立即取得显示为 LogicalRepWorker 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/LogicalRepWorker 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'LogicalRepWorker'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'LogicalRepWorker'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

27 - LWLock: MultiXactGen

等待读取或更新共享 multixact 状态。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新共享 multixact 状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/multixact.c:738。探针覆盖的操作是:等待读取或更新共享 multixact 状态。LWLockAcquire 无法立即取得显示为 MultiXactGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

28 - LWLock: MultiXactMemberBuffer

等待 multixact member SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactMemberBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 multixact member SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:144。探针覆盖的操作是:等待 multixact member SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 MultiXactMemberBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactMemberBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactMemberBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactMemberBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

29 - LWLock: MultiXactMemberSLRU

等待访问 multixact member SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactMemberSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 multixact member SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

此锁保护 pg_multixact/members 的 SLRU 缓存;这里保存共享行锁使用的 multitransaction ID 成员事务。并发行锁创建与旧成员查询会在这里相遇。

正常还是麻烦?

  • 正常: 使用 SELECT FOR SHARE/KEY SHARE,或因外键检查创建 multixact 的负载中会短暂出现。
  • 需要调查: 持续竞争指向大量共享行锁、multixact 抖动、冻结落后,或 pg_multixact 存储缓慢。

诊断 SQL

正在等待 LWLock/MultiXactMemberSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactMemberSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactMemberSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 找出制造大量共享行锁的语句与表。
  2. 检查 multixact 年龄与 autovacuum 进度。
  3. 降低锁扇出并解除 multixact 冻结阻塞;若同时出现 buffer 等待,再查 member SLRU I/O。

源码证据

典型事故模式

高扇出的外键负载锁住大量父表行,同时长事务推迟 multixact 清理,最终引发 member 缓存竞争。

30 - LWLock: MultiXactOffsetBuffer

等待 multixact offset SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactOffsetBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 multixact offset SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:143。探针覆盖的操作是:等待 multixact offset SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 MultiXactOffsetBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactOffsetBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactOffsetBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactOffsetBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

31 - LWLock: MultiXactOffsetSLRU

等待访问 multixact offset SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactOffsetSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 multixact offset SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:173。探针覆盖的操作是:等待访问 multixact offset SLRU 缓存。LWLockAcquire 无法立即取得显示为 MultiXactOffsetSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactOffsetSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactOffsetSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactOffsetSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

32 - LWLock: MultiXactTruncation

等待读取或截断 multixact 信息。
PostgreSQL 等待事件档案
类别LWLock 事件MultiXactTruncation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或截断 multixact 信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/multixact.c:2901。探针覆盖的操作是:等待读取或截断 multixact 信息。LWLockAcquire 无法立即取得显示为 MultiXactTruncation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/MultiXactTruncation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'MultiXactTruncation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'MultiXactTruncation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

33 - LWLock: NotifyBuffer

等待 NOTIFY 消息 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待 NOTIFY 消息 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:145。探针覆盖的操作是:等待 NOTIFY 消息 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 NotifyBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

34 - LWLock: NotifyQueue

等待读取或更新 NOTIFY 消息。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyQueue 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 NOTIFY 消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/async.c:940。探针覆盖的操作是:等待读取或更新 NOTIFY 消息。LWLockAcquire 无法立即取得显示为 NotifyQueue 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyQueue 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyQueue'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyQueue'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

35 - LWLock: NotifyQueueTail

等待更新 NOTIFY 消息的存储上限。
PostgreSQL 等待事件档案
类别LWLock 事件NotifyQueueTail 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新 NOTIFY 消息的存储上限。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/async.c:2126。探针覆盖的操作是:等待更新 NOTIFY 消息的存储上限。LWLockAcquire 无法立即取得显示为 NotifyQueueTail 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifyQueueTail 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifyQueueTail'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifyQueueTail'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

36 - LWLock: NotifySLRU

等待访问 NOTIFY 消息 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件NotifySLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问 NOTIFY 消息 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:175。探针覆盖的操作是:等待访问 NOTIFY 消息 SLRU 缓存。LWLockAcquire 无法立即取得显示为 NotifySLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/NotifySLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'NotifySLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'NotifySLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

37 - LWLock: OidGen

等待分配新的 OID。
PostgreSQL 等待事件档案
类别LWLock 事件OidGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配新的 OID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:563。探针覆盖的操作是:等待分配新的 OID。LWLockAcquire 无法立即取得显示为 OidGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/OidGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'OidGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'OidGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

38 - LWLock: OldSnapshotTimeMap

等待读取或更新旧快照控制信息。
PostgreSQL 等待事件档案
类别LWLock 事件OldSnapshotTimeMap 版本PG 13-16 证据2 个源码位置

官方描述译文

等待读取或更新旧快照控制信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ — —

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:750,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/time/snapmgr.c:1758。探针覆盖的操作是:等待读取或更新旧快照控制信息。LWLockAcquire 无法立即取得显示为 OldSnapshotTimeMap 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/OldSnapshotTimeMap 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'OldSnapshotTimeMap'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'OldSnapshotTimeMap'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

39 - LWLock: ParallelAppend

执行 Parallel Append 计划期间,等待选择下一个子计划。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelAppend 版本PG 13-18 证据3 个源码位置

官方描述译文

执行 Parallel Append 计划期间,等待选择下一个子计划。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/executor/nodeAppend.c:69。探针覆盖的操作是:执行 Parallel Append 计划期间,等待选择下一个子计划。LWLockAcquire 无法立即取得显示为 ParallelAppend 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelAppend 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelAppend'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelAppend'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

40 - LWLock: ParallelBtreeScan

执行 Parallel B-tree Scan 计划期间,等待同步 worker。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelBtreeScan 版本PG 18 证据3 个源码位置

官方描述译文

执行 Parallel B-tree Scan 计划期间,等待同步 worker。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — — ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:156。探针覆盖的操作是:执行 Parallel B-tree Scan 计划期间,等待同步 worker。LWLockAcquire 无法立即取得显示为 ParallelBtreeScan 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelBtreeScan 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelBtreeScan'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelBtreeScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

41 - LWLock: ParallelHashJoin

执行 Parallel Hash Join 计划期间,等待同步 worker。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelHashJoin 版本PG 13-18 证据3 个源码位置

官方描述译文

执行 Parallel Hash Join 计划期间,等待同步 worker。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/executor/nodeHash.c:71。探针覆盖的操作是:执行 Parallel Hash Join 计划期间,等待同步 worker。LWLockAcquire 无法立即取得显示为 ParallelHashJoin 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelHashJoin 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelHashJoin'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelHashJoin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

42 - LWLock: ParallelQueryDSA

等待并行查询的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelQueryDSA 版本PG 13-18 证据3 个源码位置

官方描述译文

等待并行查询的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:157。探针覆盖的操作是:等待并行查询的动态共享内存分配。LWLockAcquire 无法立即取得显示为 ParallelQueryDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelQueryDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelQueryDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelQueryDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

43 - LWLock: ParallelVacuumDSA

等待并行 vacuum 的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件ParallelVacuumDSA 版本PG 17-18 证据3 个源码位置

官方描述译文

等待并行 vacuum 的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:179。探针覆盖的操作是:等待并行 vacuum 的动态共享内存分配。LWLockAcquire 无法立即取得显示为 ParallelVacuumDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ParallelVacuumDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ParallelVacuumDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ParallelVacuumDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

44 - LWLock: PerSessionDSA

等待并行查询的动态共享内存分配。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionDSA 版本PG 13-18 证据3 个源码位置

官方描述译文

等待并行查询的动态共享内存分配。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:158。探针覆盖的操作是:等待并行查询的动态共享内存分配。LWLockAcquire 无法立即取得显示为 PerSessionDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

45 - LWLock: PerSessionRecordType

等待访问并行查询的复合类型信息。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionRecordType 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问并行查询的复合类型信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:159。探针覆盖的操作是:等待访问并行查询的复合类型信息。LWLockAcquire 无法立即取得显示为 PerSessionRecordType 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionRecordType 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionRecordType'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionRecordType'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

46 - LWLock: PerSessionRecordTypmod

等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。
PostgreSQL 等待事件档案
类别LWLock 事件PerSessionRecordTypmod 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:160。探针覆盖的操作是:等待访问并行查询中用于标识匿名 record 类型的类型修饰符信息。LWLockAcquire 无法立即取得显示为 PerSessionRecordTypmod 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerSessionRecordTypmod 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerSessionRecordTypmod'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerSessionRecordTypmod'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

47 - LWLock: PerXactPredicateList

并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。
PostgreSQL 等待事件档案
类别LWLock 事件PerXactPredicateList 版本PG 13-18 证据3 个源码位置

官方描述译文

并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:164。探针覆盖的操作是:并行查询期间,等待访问当前可串行化事务所持有的谓词锁列表。LWLockAcquire 无法立即取得显示为 PerXactPredicateList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PerXactPredicateList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PerXactPredicateList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PerXactPredicateList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

48 - LWLock: PgStatsDSA

等待访问统计信息的动态共享内存分配器。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsDSA 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问统计信息的动态共享内存分配器。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:165。探针覆盖的操作是:等待访问统计信息的动态共享内存分配器。LWLockAcquire 无法立即取得显示为 PgStatsDSA 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsDSA 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsDSA'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsDSA'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

49 - LWLock: PgStatsData

等待访问共享内存中的统计数据。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsData 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问共享内存中的统计数据。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:167。探针覆盖的操作是:等待访问共享内存中的统计数据。LWLockAcquire 无法立即取得显示为 PgStatsData 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsData 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsData'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsData'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

50 - LWLock: PgStatsHash

等待访问统计信息的共享内存哈希表。
PostgreSQL 等待事件档案
类别LWLock 事件PgStatsHash 版本PG 15-18 证据3 个源码位置

官方描述译文

等待访问统计信息的共享内存哈希表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:166。探针覆盖的操作是:等待访问统计信息的共享内存哈希表。LWLockAcquire 无法立即取得显示为 PgStatsHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PgStatsHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PgStatsHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PgStatsHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

51 - LWLock: PredicateLockManager

等待访问可串行化事务使用的谓词锁信息。
PostgreSQL 等待事件档案
类别LWLock 事件PredicateLockManager 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务使用的谓词锁信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:154。探针覆盖的操作是:等待访问可串行化事务使用的谓词锁信息。LWLockAcquire 无法立即取得显示为 PredicateLockManager 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/PredicateLockManager 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'PredicateLockManager'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'PredicateLockManager'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

52 - LWLock: ProcArray

等待访问共享的进程级数据结构(通常用于获取快照或报告会话的事务 ID)。
PostgreSQL 等待事件档案
类别LWLock 事件ProcArray 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问共享的进程级数据结构(通常用于获取快照或报告会话的事务 ID)。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

ProcArrayLock 保护用于快照、事务可见性与事务结束处理的共享 PGPROC/PGXACT 数组。获取快照以及更新进程事务状态都必须短暂经过它协调。

正常还是麻烦?

  • 正常: 大量事务开始与结束的繁忙 OLTP 系统中,短暂等待属于预期。
  • 需要调查: 持续竞争可能伴随极高连接数、大量快照、长事务,或事务集中结束。

诊断 SQL

正在等待 LWLock/ProcArray 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ProcArray'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ProcArray'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 测量活动后端与事务年龄,不要只看总连接数。
  2. 找出让可见性边界停滞的长事务与 idle in transaction 会话。
  3. 使用连接池、缩短事务,并避免大量微事务同步突发。

源码证据

典型事故模式

应用重连风暴制造数千个短事务,同时报表查询持有旧快照,放大了 ProcArray 流量。

53 - LWLock: RelCacheInit

等待读取或更新 pg_internal.init relation cache 初始化文件。
PostgreSQL 等待事件档案
类别LWLock 事件RelCacheInit 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_internal.init relation cache 初始化文件。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:323。探针覆盖的操作是:等待读取或更新 pg_internal.init relation cache 初始化文件。LWLockAcquire 无法立即取得显示为 RelCacheInit 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/RelCacheInit 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'RelCacheInit'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'RelCacheInit'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

54 - LWLock: RelationMapping

等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。
PostgreSQL 等待事件档案
类别LWLock 事件RelationMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event_names.txt:332。探针覆盖的操作是:等待读取或更新 pg_filenode.map 文件(用于跟踪某些系统目录的 filenode 分配)。LWLockAcquire 无法立即取得显示为 RelationMapping 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/RelationMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'RelationMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'RelationMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

55 - LWLock: ReplicationOrigin

等待创建、删除或使用复制源。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationOrigin 版本PG 13-18 证据3 个源码位置

官方描述译文

等待创建、删除或使用复制源。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/origin.c:377。探针覆盖的操作是:等待创建、删除或使用复制源。LWLockAcquire 无法立即取得显示为 ReplicationOrigin 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationOrigin 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationOrigin'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationOrigin'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

56 - LWLock: ReplicationOriginState

等待读取或更新一个复制源的进度。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationOriginState 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新一个复制源的进度。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/origin.c:557。探针覆盖的操作是:等待读取或更新一个复制源的进度。LWLockAcquire 无法立即取得显示为 ReplicationOriginState 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationOriginState 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationOriginState'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationOriginState'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

57 - LWLock: ReplicationSlotAllocation

等待分配或释放复制槽。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotAllocation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配或释放复制槽。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/slotsync.c:543。探针覆盖的操作是:等待分配或释放复制槽。LWLockAcquire 无法立即取得显示为 ReplicationSlotAllocation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotAllocation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotAllocation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotAllocation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

58 - LWLock: ReplicationSlotControl

等待读取或更新复制槽状态。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotControl 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新复制槽状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/replication/logical/logical.c:492。探针覆盖的操作是:等待读取或更新复制槽状态。LWLockAcquire 无法立即取得显示为 ReplicationSlotControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

59 - LWLock: ReplicationSlotIO

等待复制槽上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件ReplicationSlotIO 版本PG 13-18 证据3 个源码位置

官方描述译文

等待复制槽上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:150。探针覆盖的操作是:等待复制槽上的 I/O。LWLockAcquire 无法立即取得显示为 ReplicationSlotIO 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ReplicationSlotIO 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ReplicationSlotIO'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ReplicationSlotIO'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

60 - LWLock: SInvalRead

等待从共享系统目录失效队列中取出消息。
PostgreSQL 等待事件档案
类别LWLock 事件SInvalRead 版本PG 13-18 证据3 个源码位置

官方描述译文

等待从共享系统目录失效队列中取出消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/sinvaladt.c:497。探针覆盖的操作是:等待从共享系统目录失效队列中取出消息。LWLockAcquire 无法立即取得显示为 SInvalRead 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SInvalRead 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SInvalRead'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SInvalRead'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

61 - LWLock: SInvalWrite

等待向共享系统目录失效队列中添加消息。
PostgreSQL 等待事件档案
类别LWLock 事件SInvalWrite 版本PG 13-18 证据3 个源码位置

官方描述译文

等待向共享系统目录失效队列中添加消息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/sinvaladt.c:290。探针覆盖的操作是:等待向共享系统目录失效队列中添加消息。LWLockAcquire 无法立即取得显示为 SInvalWrite 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SInvalWrite 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SInvalWrite'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SInvalWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

62 - LWLock: SerialBuffer

等待可串行化事务冲突 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件SerialBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待可串行化事务冲突 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:146。探针覆盖的操作是:等待可串行化事务冲突 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 SerialBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

63 - LWLock: SerialControl

等待读取或更新共享的 pg_serial 状态。
PostgreSQL 等待事件档案
类别LWLock 事件SerialControl 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新共享的 pg_serial 状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:835。探针覆盖的操作是:等待读取或更新共享的 pg_serial 状态。LWLockAcquire 无法立即取得显示为 SerialControl 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialControl 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialControl'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialControl'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

64 - LWLock: SerialSLRU

等待访问可串行化事务冲突 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件SerialSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务冲突 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:176。探针覆盖的操作是:等待访问可串行化事务冲突 SLRU 缓存。LWLockAcquire 无法立即取得显示为 SerialSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerialSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerialSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerialSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

65 - LWLock: SerializableFinishedList

等待访问已结束的可串行化事务列表。
PostgreSQL 等待事件档案
类别LWLock 事件SerializableFinishedList 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问已结束的可串行化事务列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:1507。探针覆盖的操作是:等待访问已结束的可串行化事务列表。LWLockAcquire 无法立即取得显示为 SerializableFinishedList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializableFinishedList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializableFinishedList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializableFinishedList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

66 - LWLock: SerializablePredicateList

等待访问可串行化事务所持有的谓词锁列表。
PostgreSQL 等待事件档案
类别LWLock 事件SerializablePredicateList 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问可串行化事务所持有的谓词锁列表。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:2220。探针覆盖的操作是:等待访问可串行化事务所持有的谓词锁列表。LWLockAcquire 无法立即取得显示为 SerializablePredicateList 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializablePredicateList 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializablePredicateList'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializablePredicateList'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

67 - LWLock: SerializableXactHash

等待读取或更新可串行化事务的信息。
PostgreSQL 等待事件档案
类别LWLock 事件SerializableXactHash 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新可串行化事务的信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/predicate.c:1462。探针覆盖的操作是:等待读取或更新可串行化事务的信息。LWLockAcquire 无法立即取得显示为 SerializableXactHash 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SerializableXactHash 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SerializableXactHash'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SerializableXactHash'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

68 - LWLock: SharedTidBitmap

并行 bitmap index scan 期间,等待访问共享 TID bitmap。
PostgreSQL 等待事件档案
类别LWLock 事件SharedTidBitmap 版本PG 13-18 证据3 个源码位置

官方描述译文

并行 bitmap index scan 期间,等待访问共享 TID bitmap。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:162。探针覆盖的操作是:并行 bitmap index scan 期间,等待访问共享 TID bitmap。LWLockAcquire 无法立即取得显示为 SharedTidBitmap 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SharedTidBitmap 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SharedTidBitmap'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SharedTidBitmap'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

69 - LWLock: SharedTupleStore

并行查询期间,等待访问共享 tuple store。
PostgreSQL 等待事件档案
类别LWLock 事件SharedTupleStore 版本PG 13-18 证据3 个源码位置

官方描述译文

并行查询期间,等待访问共享 tuple store。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:161。探针覆盖的操作是:并行查询期间,等待访问共享 tuple store。LWLockAcquire 无法立即取得显示为 SharedTupleStore 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SharedTupleStore 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SharedTupleStore'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SharedTupleStore'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

70 - LWLock: ShmemIndex

等待在共享内存中查找或分配空间。
PostgreSQL 等待事件档案
类别LWLock 事件ShmemIndex 版本PG 13-18 证据3 个源码位置

官方描述译文

等待在共享内存中查找或分配空间。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/ipc/shmem.c:392。探针覆盖的操作是:等待在共享内存中查找或分配空间。LWLockAcquire 无法立即取得显示为 ShmemIndex 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/ShmemIndex 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'ShmemIndex'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'ShmemIndex'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

71 - LWLock: SubtransBuffer

等待子事务 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件SubtransBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待子事务 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:142。探针覆盖的操作是:等待子事务 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 SubtransBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SubtransBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SubtransBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SubtransBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

72 - LWLock: SubtransSLRU

等待访问子事务 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件SubtransSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问子事务 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:177。探针覆盖的操作是:等待访问子事务 SLRU 缓存。LWLockAcquire 无法立即取得显示为 SubtransSLRU 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SubtransSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SubtransSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SubtransSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

73 - LWLock: SyncRep

等待读取或更新同步复制状态信息。
PostgreSQL 等待事件档案
类别LWLock 事件SyncRep 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新同步复制状态信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

SyncRepLock 保护同步复制队列与共享 sender 状态。提交会话入队或检查等待位置,WAL sender 则更新已被同步备库确认的 LSN。

正常还是麻烦?

  • 正常: 同步提交排队、WAL sender 发布确认位置时会有小规模突发。
  • 需要调查: 持续的 SyncRep LWLock 竞争不同于等待备库确认:它表示队列/状态协调本身过热,通常发生在极高提交并发或 sender 抖动时。

诊断 SQL

正在等待 LWLock/SyncRep 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SyncRep'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SyncRep'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 区分 LWLock/SyncRep、IPC/SyncRep 与复制延迟等待。
  2. 检查同步备库健康度、sender 抖动与提交速率。
  3. 稳定复制并平滑提交突发;只有获得明确事故授权时才改变持久性策略。

源码证据

典型事故模式

备库反复抖动,大量同步提交者频繁进出等待队列,使队列协调本身表现为 LWLock/SyncRep。

74 - LWLock: SyncScan

等待选择同步表扫描的起始位置。
PostgreSQL 等待事件档案
类别LWLock 事件SyncScan 版本PG 13-18 证据3 个源码位置

官方描述译文

等待选择同步表扫描的起始位置。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/common/syncscan.c:258。探针覆盖的操作是:等待选择同步表扫描的起始位置。LWLockAcquire 无法立即取得显示为 SyncScan 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/SyncScan 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'SyncScan'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'SyncScan'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

75 - LWLock: TablespaceCreate

等待创建或删除表空间。
PostgreSQL 等待事件档案
类别LWLock 事件TablespaceCreate 版本PG 13-18 证据3 个源码位置

官方描述译文

等待创建或删除表空间。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/tablespace.c:138。探针覆盖的操作是:等待创建或删除表空间。LWLockAcquire 无法立即取得显示为 TablespaceCreate 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/TablespaceCreate 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'TablespaceCreate'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'TablespaceCreate'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

76 - LWLock: TwoPhaseState

等待读取或更新预备事务的状态。
PostgreSQL 等待事件档案
类别LWLock 事件TwoPhaseState 版本PG 13-18 证据3 个源码位置

官方描述译文

等待读取或更新预备事务的状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/twophase.c:329。探针覆盖的操作是:等待读取或更新预备事务的状态。LWLockAcquire 无法立即取得显示为 TwoPhaseState 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/TwoPhaseState 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'TwoPhaseState'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'TwoPhaseState'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

77 - LWLock: WALBufMapping

等待替换 WAL buffer 中的页面。
PostgreSQL 等待事件档案
类别LWLock 事件WALBufMapping 版本PG 13-18 证据3 个源码位置

官方描述译文

等待替换 WAL buffer 中的页面。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WALBufMappingLock 协调 WAL 页号与有限 wal_buffers 槽位之间的映射。后端推进到新 WAL 页或替换缓冲页时需要取得此锁。

正常还是麻烦?

  • 正常: WAL 生成推进并跨越缓冲页时会短暂出现。
  • 需要调查: 持续竞争说明 WAL 生成换页速度超过写路径推进速度,常见于写突发或检查点期间。

诊断 SQL

正在等待 LWLock/WALBufMapping 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALBufMapping'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALBufMapping'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 关联 WAL 字节量、WAL 写入与检查点时间。
  2. 检查写突发期间 wal_buffers 是否反复耗尽。
  3. 先平滑写突发并解决 WAL 设备延迟,再调整缓冲区大小。

源码证据

典型事故模式

批量导入把 WAL 生成推到极限,同时 WAL 设备发生停顿,导致频繁的 WAL 缓冲页重映射。

78 - LWLock: WALInsert

等待将 WAL 数据插入内存 buffer。
PostgreSQL 等待事件档案
类别LWLock 事件WALInsert 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将 WAL 数据插入内存 buffer。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

后端在共享 WAL 缓冲区中预留空间并复制 WAL 记录时,必须持有一个 WAL insertion lock。并发 WAL 生产者很多、插入临界区变长时,会在此排队。

正常还是麻烦?

  • 正常: 并发写入与提交突发期间的瞬时等待很正常。
  • 需要调查: 前台会话反复堆积说明 WAL 插入已成为串行点,常伴随极高写并发、全页镜像或缓冲区换页过慢。

诊断 SQL

正在等待 LWLock/WALInsert 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALInsert'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALInsert'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 按 WAL 生成量与调用频率排序语句。
  2. 检查检查点/全页镜像时机与并发写会话数量。
  3. 批量合并微小写入、减少无效索引抖动,并处理 WAL 写延迟。

源码证据

典型事故模式

扇出任务在检查点后立即发起大量单行提交,全页镜像与写并发共同让 WAL 插入成为瓶颈。

79 - LWLock: WALSummarizer

等待读取或更新 WAL 汇总状态。
PostgreSQL 等待事件档案
类别LWLock 事件WALSummarizer 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新 WAL 汇总状态。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/postmaster/walsummarizer.c:273。探针覆盖的操作是:等待读取或更新 WAL 汇总状态。LWLockAcquire 无法立即取得显示为 WALSummarizer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WALSummarizer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALSummarizer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALSummarizer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

80 - LWLock: WALWrite

等待将 WAL buffer 写入磁盘。
PostgreSQL 等待事件档案
类别LWLock 事件WALWrite 版本PG 13-18 证据3 个源码位置

官方描述译文

等待将 WAL buffer 写入磁盘。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

WALWriteLock 串行化共享 WAL 缓冲区写入,以及 written/flushed 位置的推进。等待者正在当前执行或协调这项工作的后端之后排队。

正常还是麻烦?

  • 正常: 多个提交者协助写 WAL 时会短暂出现。
  • 需要调查: WALWrite 持续出现且提交延迟上升,通常表示 WAL 写路径变慢,或吞吐跟不上 WAL 生成速度。

诊断 SQL

正在等待 LWLock/WALWrite 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WALWrite'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WALWrite'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 把 WAL write/sync 时间与提交延迟对照。
  2. 检查 WAL 文件系统/设备、虚拟化限速与检查点重叠。
  3. 降低突发性;只有存储证据确认后才调整 wal_writer 参数。

源码证据

典型事故模式

云盘耗尽突发积分,WAL 写入变长,提交会话在 WALWrite 上排队,同步提交延迟同步恶化。

81 - LWLock: WaitEventCustom

等待读取或更新自定义等待事件信息。
PostgreSQL 等待事件档案
类别LWLock 事件WaitEventCustom 版本PG 17-18 证据3 个源码位置

官方描述译文

等待读取或更新自定义等待事件信息。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
— — — — ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/utils/activity/wait_event.c:193。探针覆盖的操作是:等待读取或更新自定义等待事件信息。LWLockAcquire 无法立即取得显示为 WaitEventCustom 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WaitEventCustom 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WaitEventCustom'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WaitEventCustom'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

82 - LWLock: WrapLimitsVacuum

等待更新事务 ID 和 multixact 的消耗上限。
PostgreSQL 等待事件档案
类别LWLock 事件WrapLimitsVacuum 版本PG 13-18 证据3 个源码位置

官方描述译文

等待更新事务 ID 和 multixact 的消耗上限。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/commands/vacuum.c:1858。探针覆盖的操作是:等待更新事务 ID 和 multixact 的消耗上限。LWLockAcquire 无法立即取得显示为 WrapLimitsVacuum 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/WrapLimitsVacuum 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'WrapLimitsVacuum'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'WrapLimitsVacuum'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

83 - LWLock: XactBuffer

等待事务状态 SLRU buffer 上的 I/O。
PostgreSQL 等待事件档案
类别LWLock 事件XactBuffer 版本PG 13-18 证据3 个源码位置

官方描述译文

等待事务状态 SLRU buffer 上的 I/O。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/storage/lmgr/lwlock.c:140。探针覆盖的操作是:等待事务状态 SLRU buffer 上的 I/O。LWLockAcquire 无法立即取得显示为 XactBuffer 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XactBuffer 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactBuffer'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactBuffer'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

84 - LWLock: XactSLRU

等待访问事务状态 SLRU 缓存。
PostgreSQL 等待事件档案
类别LWLock 事件XactSLRU 版本PG 13-18 证据3 个源码位置

官方描述译文

等待访问事务状态 SLRU 缓存。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

事务状态 SLRU 锁保护 pg_xact 缓存元数据与页面,PostgreSQL 读取或更新事务提交状态时会经过这里。对未缓存或很老 XID 的可见性检查会把这条路径带到前台。

正常还是麻烦?

  • 正常: 事务结束与偶发 pg_xact 缓存未命中会带来短暂等待。
  • 需要调查: 持续等待可能表示事务状态缓存抖动、访问很老的元组,或 pg_xact 路径存在存储延迟。

诊断 SQL

正在等待 LWLock/XactSLRU 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactSLRU'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactSLRU'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 检查老事务以及 vacuum/freeze 健康度。
  2. 关联 XactBuffer 与 pg_xact I/O 等待。
  3. 先消除可见性边界阻塞者并恢复清理进度,再考虑容量调整。

源码证据

典型事故模式

长生命周期快照阻止清理,同时查询反复访问冷的旧元组版本,引发 pg_xact 缓存抖动与 XactSLRU 竞争。

85 - LWLock: XactTruncation

等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。
PostgreSQL 等待事件档案
类别LWLock 事件XactTruncation 版本PG 13-18 证据3 个源码位置

官方描述译文

等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:357。探针覆盖的操作是:等待执行 pg_xact_status,或更新当前进程可用的最旧事务 ID。LWLockAcquire 无法立即取得显示为 XactTruncation 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XactTruncation 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XactTruncation'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XactTruncation'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据

86 - LWLock: XidGen

等待分配新的事务 ID。
PostgreSQL 等待事件档案
类别LWLock 事件XidGen 版本PG 13-18 证据3 个源码位置

官方描述译文

等待分配新的事务 ID。

PG 13 PG 14 PG 15 PG 16 PG 17 PG 18
✓ ✓ ✓ ✓ ✓ ✓

触发机制

pgstat_report_wait_start 位于 src/backend/storage/lmgr/lwlock.c:739,是经 grep 核验的报告路径。公共身份/资源映射位于 src/backend/access/transam/varsup.c:105。探针覆盖的操作是:等待分配新的事务 ID。LWLockAcquire 无法立即取得显示为 XidGen 的轻量级锁 tranche;后端在内部共享内存资源上休眠时,通用 LWLock 报告器发布该 tranche 名称。

正常还是麻烦?

  • 正常: 短暂内部临界区周围的零星样本属于正常。
  • 需要调查: 若同一 tranche 在连续三次一秒采样中影响至少 10% 的活动前台会话,应当调查;达到 25% 或持续超过五秒按紧急处理。

诊断 SQL

正在等待 LWLock/XidGen 的会话
SELECT pid, backend_type, usename, datname, application_name,
       state, now() - query_start AS query_age,
       now() - xact_start AS xact_age,
       wait_event_type, wait_event,
       pg_blocking_pids(pid) AS blocking_pids,
       left(query, 160) AS query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
  AND wait_event = 'XidGen'
ORDER BY query_age DESC NULLS LAST;
当前 LWLock 等待分布
SELECT wait_event, count(*) AS waiting_sessions,
       count(*) FILTER (WHERE state = 'active') AS active_waiters,
       max(now() - query_start) AS oldest_query
FROM pg_stat_activity
WHERE wait_event_type = 'LWLock'
GROUP BY wait_event
ORDER BY waiting_sessions DESC, wait_event;
这些会话的锁与关系上下文
SELECT a.pid, l.locktype, l.mode, l.granted, l.fastpath,
       d.datname, n.nspname, c.relname,
       l.page, l.tuple, l.virtualxid, l.transactionid,
       l.classid, l.objid, l.objsubid
FROM pg_stat_activity AS a
LEFT JOIN pg_locks AS l ON l.pid = a.pid
LEFT JOIN pg_database AS d ON d.oid = l.database
LEFT JOIN pg_class AS c
  ON c.oid = l.relation
 AND l.database = (
       SELECT oid FROM pg_database WHERE datname = current_database()
     )
LEFT JOIN pg_namespace AS n ON n.oid = c.relnamespace
WHERE a.wait_event_type = 'LWLock'
  AND a.wait_event = 'XidGen'
ORDER BY a.pid, l.granted, l.locktype, l.mode;

处置建议

  1. 重复采样并锁定一个热点 tranche。
  2. 把它与受保护资源及当前负载阶段关联。
  3. 降低具体竞争源;增加并发可能让共享内存热点更糟。

源码证据