pgrac 在 PostgreSQL 原生 9 类等待事件之上设计了 10 个 Cluster:* 类共 46 个事件(完整 taxonomy 见 wait-events-design.md §2.1)。本章是这份设计目标的完整目录,并对每一个事件标注其 Stage 可用性——Stage 2 当前只实装了一个真子集,其余事件是 Stage 3-6 的产线规划目标。叙述刻意精炼;时序图、状态机、告警阈值见设计文档原文。
本章反映的是完整设计目标(46 个事件 / 10 个类)。spec-0.11 在 Stage 0 阶段已把 46 个事件名 + 10 个类 ID(0x10000000..0x19000000)注册到 catalog——它们出现在 pg_wait_events 系统视图,但 Stage 2 完全没有 pgstat_report_wait_start 调用站点(L62 wait-event-registration ≠ runtime 反模式;详见 docs/spec-drafting-lessons.md L62 / L13)。Stage 2 实际计时的是另一组以 WAIT_EVENT_CLUSTER_* 命名的更细粒度事件——见 §6.13。
pgrac 的等待事件框架对 PG 的 pgstat_report_wait_start / pgstat_report_wait_end API 保持源码兼容;新增事件全部挂在 Cluster: 前缀下,子类用空格 + 名称组织(例如 Cluster: PCM、Cluster: BufferShip)。每个事件的 Stage 标签遵循以下规则:
| Stage 标签 | 含义 |
|---|---|
Stage 0 catalog | spec-0.11 注册了 enum 名,出现在 pg_wait_events 视图;无 runtime 调用站点(decorative surface) |
Stage 3 design target | 规划在 Stage 3(MVCC + Undo + CR build)实装 |
Stage 4 design target | 规划在 Stage 4(WAL + crash recovery)实装 |
Stage 5 design target | 规划在 Stage 5(完整 RAC core + GES 8-mode)实装 |
Stage 6 design target | 规划在 Stage 6(RDMA / DRM / ADG / production)实装 |
Stage 标签依据 docs/stage2-6-detailed-spec-roadmap.md 的子系统归属推导;具体 spec 编号在每行注释中给出。Stage 标签不代表 spec 已 freeze——只代表该子系统所在 Stage 的设计意图。
| 类 | 设计事件数 | ID base | 关注点 |
|---|---|---|---|
Cluster: GES | 5 | 0x10000000 | 全局排队服务——锁请求、master 查询、convert / release |
Cluster: PCM | 6 | 0x11000000 | Page Consistency Manager——块状态转换 N→S / N→X / S→X 等 |
Cluster: BufferShip | 5 | 0x12000000 | Cache Fusion——CR / current 块在节点间传输 |
Cluster: SCN | 4 | 0x13000000 | System Change Number——BOC flush、piggyback、跨节点比较 |
Cluster: Reconfig | 5 | 0x14000000 | 成员变更——GRD 重建、lock recovery、fence、master 选举、barrier |
Cluster: Recovery | 5 | 0x15000000 | Crash recovery——WAL 拉取、k-way merge、并行 apply、PCM 状态恢复 |
Cluster: Sinval | 3 | 0x16000000 | 共享 invalidation——跨节点 catcache / relcache 失效广播 |
Cluster: Interconnect | 5 | 0x17000000 | 互联传输——RDMA send / recv、TCP fallback、tier 切换、connect retry |
Cluster: Undo | 4 | 0x18000000 | 远程 undo——CR build 读远程 undo block / TT slot、batch fetch、retention |
Cluster: ADG | 4 | 0x19000000 | Active Data Guard——MRP apply、WAL receive、read snapshot、SCN sync |
| 合计 | 46 | — | 每类预留 256 个 ID 槽位 |
| 项 | 数值 | 来源 |
|---|---|---|
| 设计目标(完整 taxonomy) | 10 类 / 46 事件 | wait-events-design.md §2.1 |
| Stage 0 catalog 注册(无 runtime) | 46 / 46 | spec-0.11 §3 enum 一次性注册 |
| Stage 2 实装的设计目标事件 | 0 / 46 | 2026-05-16 spec corpus 全 grep 无 pgstat_report_wait_start(WAIT_EVENT_GES_*/PCM_*/...) 调用站点 |
| Stage 2 实际新增并 wired 的事件(taxonomy 之外) | 23 | spec-2.2 / 2.4 / 2.5 / 2.6 / 2.18-2.23 / 2.28 / 2.29——见 §6.13 |
pg_wait_events 总计数(Stage 2 完结) | 66 | spec-2.29 §D14 wait_events 65→66 baseline |
| 视图 | 说明 |
|---|---|
pg_wait_events(PG 原生) | 列出 catalog 内所有等待事件名与类型;46 个设计目标事件 + Stage 2 实装的 Cluster 事件全部自动出现 |
pg_stat_cluster_wait_events | 按事件聚合的累计 call count + 等待时长;Stage 2 期间设计目标事件这一行 calls = 0(catalog-only) |
pg_stat_cluster_wait_events_history | 时间分桶切片(默认每 10 秒一桶,环形 buffer 保留近 1 小时) |
pg_stat_activity.wait_event / wait_event_type | 当前 backend 实时等待——pgrac 事件直接出现,无 schema 变更 |
Cluster: 大类下;子类名用空格分隔(Cluster: PCM)。PCM block read N→S、GES enqueue acquire。(sampled) 后缀,按 1/100 采样后由 Cluster Stats 进程聚合。pgstat_report_wait_start / pgstat_report_wait_end,debug build 用 assertion 检测嵌套违规(INV1 不重叠)。GES(Global Enqueue Service)等待事件覆盖全局锁请求、模式转换、释放确认、master 查询。Stage 2 已 ship LMS / LMD daemon skeleton + 7-step state machine + 跨节点 deadlock(spec-2.18-2.23),但这些路径上没有插入 GES taxonomy 的 5 个 wait event;Stage 2 实际计时的是 GesS4Wait / GesS4Reply / GesReplyWait(更细粒度,见 §6.13)。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
GES enqueue acquire | Stage 5 design target | 锁请求进入 LMD 队列,等待 master 授予 | 8 μs(无冲突)/ ms–s(持有者未释放) |
GES enqueue convert | Stage 5 design target | 已持锁需升级模式(S→X 等) | 10–15 μs(无冲突)/ 数十 ms(协调) |
GES enqueue release ack | Stage 5 design target | LockRelease 发出 RELEASE 消息后等待 master RELEASE_ACK | 5–7 μs |
GES master query | Stage 5 design target | GRD cache miss 时广播查询资源 master node_id | 5–10 μs |
GES local fast path (sampled) | Stage 5 design target | 本节点已是 master 且无冲突——纯本地 GRD 查找 | < 1 μs(按 1/100 采样) |
Stage 归属:Stage 5 spec 5.1 (Full GES 8-mode lock matrix)。Stage 0 catalog enum 注册于 spec-0.11 §3。
PCM(Page Consistency Manager)等待事件覆盖块级状态转换:从 N(无副本)到 S / X、跨节点降级、ITL cleanout 引发的临时升级。PCM 9-state machine 在 Stage 2 spec roadmap 的 spec-2.26 范围(尚未 freeze);实际激活路径在 Stage 2 后期 + Stage 3。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
PCM block read N→S | Stage 3 design target | backend 首次读块,本节点无副本,从 master / 持有者获取 S 副本 | 9–18 μs |
PCM block read N→X | Stage 3 design target | UPDATE/DELETE 路径直接请求独占模式 | 10–15 μs |
PCM block write S→X | Stage 3 design target | 本节点持有 S 副本,写操作触发 S→X 升级 | 12–20 μs |
PCM block convert wait | Stage 3 design target | master convert queue 非空;本请求入队待调度 | < 50 μs(正常)/ ms(高峰) |
PCM block downgrade | Stage 3 design target | LMS 收到 master downgrade 请求,含 PI 创建 | 3–10 μs(无 dirty)/ 1–100 ms(含 dirty 写回) |
PCM ITL cleanout | Stage 3 design target | 读块时检测 ITL 需清理,触发临时 S→X 升级 | 15–25 μs |
Stage 归属:Stage 3 spec 3.6-3.8 (ITL slot / cleanout) + Stage 2 spec-2.26 (PCM 9-state activation,尚未 freeze)。
BufferShip 等待事件覆盖 Cache Fusion 路径——CR 块构造与跨节点传输、current 块的发送 / 接收。Buffer ship cr build 归属 LMS 进程而非 backend(LMS-attributed)。Cache Fusion 2-way / 3-way 协议在 Stage 2 spec roadmap 的 spec-2.30 / 2.31 范围(尚未 freeze)。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Buffer ship cr build (LMS-attributed) | Stage 3 design target | LMS 根据 UNDO 链构造 CR 版本块 | 5–15 μs |
Buffer ship cr send | Stage 3 design target | CR 块通过 IC 发往请求节点 | 2–5 μs(含 RDMA) |
Buffer ship cr receive | Stage 3 design target | backend 等待 CR 块到达并 install 到 CR chain | 10–20 μs(2-way / 3-way) |
Buffer ship current send | Stage 3 design target | 持有者 LMS 将 current 块 ship 给请求节点 | 2–5 μs |
Buffer ship current receive | Stage 3 design target | DML 路径接收对端 ship 的 current 块 | 10–18 μs |
Stage 归属:Stage 3 spec 3.12-3.13 (CR block construction / cache);依赖 Stage 2 spec-2.30/2.31 Cache Fusion 协议。
SCN(System Change Number)等待事件覆盖 commit boundary 上的 SCN flush、消息内 piggyback 推进、跨节点比较、广播。Stage 1.17 已 ship walwriter BOC 框架;Stage 2 spec-2.9-2.12 ship 了 SCN broadcast / piggyback / cross-instance lookup 的 observability,但这些路径上没有插入 SCN taxonomy 的 4 个 wait event。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
SCN BOC flush wait | Stage 3 design target | Batch on Commit——commit 边界 flush 累积的 SCN 推进 | ~100 μs |
SCN piggyback merge (sampled) | Stage 3 design target | 入站消息携带 piggyback SCN > local_scn,CAS 推进 | 0.5–1 μs(按 1/100 采样) |
SCN cross-node compare | Stage 3 design target | 跨节点 SCN 比较(scn_recovery_cmp(),含 LSN + node_id tie-break) | 1–3 μs |
SCN advance broadcast | Stage 3 design target | 本节点 SCN 推进后广播给其他节点 | 3–8 μs |
Stage 归属:Stage 3 spec 3.9 (cluster snapshot read_scn) + 已有 walwriter BOC 框架(Stage 1)。Stage 2 spec-2.9-2.12 仅 ship observability,未 wire wait event。
Reconfig 等待事件在节点加入 / 退出 / 故障期间出现。详细的 Freeze / Rebuild / Thaw 时序见第 5 章。Stage 2 ship 的 reconfig 最小闭包(spec-2.5 / 2.6 / 2.28 / 2.29)新增了一个细粒度 wait event BgProcLmonReconfigTick(归属 BgProc 类,见 §6.13),但未实装 Reconfig taxonomy 的 5 个事件;真正的 5 阶段细分推迟到 Stage 5 spec 5.12 (clean leave / fail-stop reconfig)。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Reconfig: GRD rebuild | Stage 5 design target | 节点加入 / 退出后重建全局资源目录 | 50–200 ms(4 节点)/ 300 ms–1 s(16 节点) |
Reconfig: lock recovery | Stage 5 design target | 故障节点持有的全局锁重新分配 / 释放 | 20–100 ms |
Reconfig: fence wait | Stage 5 design target | 等待 fence-lite 自隔离生效或 voting disk lease 过期 | 1–5 s |
Reconfig: master selection | Stage 5 design target | coordinator 通过 min(survivor_set) 选举完成 | 1–10 ms |
Reconfig: barrier wait | Stage 5 design target | 所有活节点到达全局 barrier 同步点 | 10–100 ms |
Stage 归属:Stage 5 spec 5.12-5.14 (reconfig + node join / leave)。Stage 2 ship 的 reconfig 最小闭包计时归属 §6.13 的 BgProcLmonReconfigTick。
Recovery 等待事件在 crash recovery 阶段出现——Recovery Worker 拉取 WAL、按 SCN 做 k-way merge、并行 apply、回放 undo、最后重建 PCM 状态。完整 crash recovery 子系统在 Stage 4 范围。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Recovery: WAL fetch | Stage 4 design target | 从共享存储 / 故障节点拉取 WAL 段 | 10–50 ms / GB(取决于存储带宽) |
Recovery: k-way merge | Stage 4 design target | 多节点 WAL stream 按 commit_scn 顺序归并 | 10–100 ms / 1 GB WAL |
Recovery: apply per-thread | Stage 4 design target | Worker 应用一段已合并 WAL | 吞吐 ~100 MB/s(per worker) |
Recovery: undo replay | Stage 4 design target | 回放未提交事务的 undo,恢复一致性快照 | 10–200 ms(取决于 in-flight 量) |
Recovery: PCM state restore | Stage 4 design target | apply 完成后重建 PCM 状态——哪个块在哪个节点持有什么锁 | 50–500 ms |
Stage 归属:Stage 4 spec 4.3-4.13 (Recovery Coordinator / Worker / k-way merge / GES/PCM/Undo recovery)。
Sinval 等待事件覆盖 catcache / relcache 跨节点失效广播。DDL 路径上每次模式变更都会触发一次集群范围的 sinval 广播。Sinval Broadcaster + 集群 invalidation 在 Stage 2 spec roadmap 的 spec-2.33 / 2.34 范围(尚未 freeze)。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Sinval broadcast send | Stage 3 design target | 本节点向所有 peer 发送 sinval 失效消息 | 2–4 μs(RDMA) |
Sinval broadcast receive | Stage 3 design target | 收到其他节点 sinval 广播,inject 到本节点 sinval queue | 3–5 μs |
Sinval inject local queue | Stage 3 design target | 消息从入站 buffer inject 到 backend-local queue | 0.5–1 μs |
Stage 归属:Stage 2 spec-2.33/2.34 (SI broadcaster / catalog cluster invalidation,尚未 freeze)→ Stage 3 dual-dimension visibility 配套。
Interconnect 等待事件覆盖 IC 传输层:RDMA send / recv(Stage 6+ 引入硬件 RDMA tier)、TCP fallback(Stage 2 默认 Tier 4)、tier 切换、connect retry。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Interconnect RDMA send | Stage 6 design target | 调用 ibv_post_send() 后等待 send completion | 1–3 μs |
Interconnect RDMA recv | Stage 6 design target | 提交 ibv_post_recv() 后等待 recv completion | 1–3 μs |
Interconnect TCP fallback | Stage 6 design target | AD-007 Tier 4:经 TCP 收发集群消息 | 50–200 μs |
Interconnect tier switch | Stage 6 design target | RDMA ↔ TCP tier 切换期间消息暂存与重路由 | 10–50 ms(切换瞬间) |
Interconnect connect retry | Stage 6 design target | peer 重连——指数退避后重试 connect | 50 ms → 1 s(exp backoff) |
Stage 归属:Stage 6 spec 6.1-6.6 (RDMA provider vtable / dual transport / tier1 send-recv / memory registration / zero-copy)。Stage 2 实际 IC 计时见 §6.13 的 6 个 IcTcp* / IcHeartbeatWait / IcReconnect 事件——它们提供了比设计 taxonomy 更细的 TCP-tier breakdown。
设计文档中 Interconnect TCP fallback 的"任何出现即告警"语义只在 Stage 6+ 装上 RDMA 后才成立——在 Stage 2 集群 TCP 是默认且唯一路径,该告警语义不适用。Stage 2 期间应监控 §6.13 的 IcTcpRecv / IcTcpSend 长尾延迟与 IcReconnect 频次。
Undo 等待事件覆盖远程 undo 访问——CR 构造时读远程节点的 undo block / TT slot、批量拉取 undo segment、长事务阻塞 undo 回收。Undo / TT 子系统在 Stage 3 范围。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
Undo remote read | Stage 3 design target | CR build 期间读取远程节点的 undo block | 10–20 μs |
Undo TT lookup remote | Stage 3 design target | 查询远程 Transaction Table slot 以获取 commit_scn | 8–15 μs |
Undo segment fetch | Stage 3 design target | 批量拉取远程 undo segment(CR build 优化路径) | 20–50 μs / segment |
Undo retention wait | Stage 3 design target | 长事务持有旧 undo,阻塞 undo segment recycle | 取决于业务(s–min) |
Stage 归属:Stage 3 spec 3.1-3.5 (Undo segment / record / tablespace / TT slot) + spec 3.14-3.15 (retention / Undo Cleaner)。
ADG(Active Data Guard)等待事件覆盖 standby 上的 MRP apply、WAL receive lag、read query 等待 apply_scn、跨节点 SCN 收敛。ADG 在 Stage 6 范围。
| 事件名 | Stage | 描述 | 典型耗时 |
|---|---|---|---|
ADG MRP apply wait | Stage 6 design target | standby MRP(Managed Recovery Process)apply 当前 WAL 段 | 取决于 WAL 速率(ms–s) |
ADG WAL receive lag | Stage 6 design target | walreceiver 落后于 primary——网络或负载导致 | 正常 < 100 ms / 异常 s 级 |
ADG read snapshot wait | Stage 6 design target | read query 等待 apply_scn 推进至所需 snapshot scn | 10–100 ms(典型) |
ADG SCN sync wait | Stage 6 design target | 跨实例 SCN 收敛——standby 端 SCN 与 primary 对齐 | 1–10 ms |
Stage 归属:Stage 6 spec 6.10-6.11 (ADG physical standby skeleton / apply lag / read-only service)。
下表汇总 §6.2-§6.11 的 46 个设计目标在 Stage 2 期间的实装计数。所有 46 个事件都在 Stage 0(spec-0.11)就把 enum 名注册进了 catalog——它们出现在 pg_wait_events——但都没有 pgstat_report_wait_start 调用站点(2026-05-16 全 spec corpus grep)。
| 类 | 设计事件数 | Stage 2 已 wired | Stage 2 catalog-only |
|---|---|---|---|
Cluster: GES | 5 | 0 | 5 |
Cluster: PCM | 6 | 0 | 6 |
Cluster: BufferShip | 5 | 0 | 5 |
Cluster: SCN | 4 | 0 | 4 |
Cluster: Reconfig | 5 | 0 | 5 |
Cluster: Recovery | 5 | 0 | 5 |
Cluster: Sinval | 3 | 0 | 3 |
Cluster: Interconnect | 5 | 0 | 5 |
Cluster: Undo | 4 | 0 | 4 |
Cluster: ADG | 4 | 0 | 4 |
| 合计 | 46 | 0 | 46 |
Stage 2 spec 在设计 taxonomy 之外新增并 wire 了 23 个细粒度事件——这些事件描述的是当前实装层的真状态(LMS / LMD daemon 的 startup / drain / idle / scan、IC TCP 收发、CSSD / Qvotec / LMON tick 等),粒度比设计 taxonomy 更细。它们都按 PG 命名约定使用 CamelCase(BgProcLmonReconfigTick),与设计 taxonomy 的空格分隔(GES enqueue acquire)区分开。
| 事件名 | Spec 来源 | 说明 |
|---|---|---|
BgProcCssdMainLoop | spec-2.5 §D8 | CSSD 心跳 daemon 主循环 idle wait |
BgProcQvotecMainLoop | spec-2.6 §Hardening | Voting disk quorum daemon 主循环 idle wait |
BgProcLmonReconfigTick | spec-2.29 §D9 | LMON tick 内执行 reconfig coordinator 决策 + epoch++ + ProcSignal broadcast 路径 |
另有 spec-1.11 / 1.12 / 1.13 / 1.14 ship 的 BgProcLmonMainLoop、BgProcLckMainLoop、BgProcDiagMainLoop、BgProcClusterStatsMainLoop 在 Stage 1 已落地,本章不展开。
| 事件名 | Spec 来源 | 说明 |
|---|---|---|
IcTcpAccept | spec-2.2 §2.5 | listener fd 等待 incoming connection |
IcTcpConnect | spec-2.2 §2.5 | active 端 nonblocking connect 等待 socket writable |
IcTcpRecv | spec-2.2 §2.5 | per-peer socket 等待 readable(读 envelope / payload) |
IcTcpSend | spec-2.2 §2.5 | per-peer socket 等待 writable(短写阻塞) |
IcHeartbeatWait | spec-2.2 §2.5 | 等待下一次 heartbeat tick(WaitLatch(WL_TIMEOUT)) |
IcReconnect | spec-2.2 §2.5 | connect failure 后 reconnect backoff sleep |
IcChunkReassembly | spec-2.4 §D10 | multi-segment frame 拼接等待 |
IcEpochEnforceDrop | spec-2.4 §D10 | stale-epoch 入站消息 drop 计时 |
| 事件名 | Spec 来源 | 说明 |
|---|---|---|
GesS4Wait | spec-2.20 §D12 / spec-2.21 §D4 | S4 远程等待——backend 发出 GES_REQUEST 后等 GES_GRANT/REJECT |
GesS4Reply | spec-2.21 §D15 | S4 reply 处理期 |
GesReplyWait | spec-2.23 §D12 | D2 backend cross-node reply 等待(BAST / production deadlock 路径) |
| 事件名 | Spec 来源 | 说明 |
|---|---|---|
LmsStartup | spec-2.18 §Q12 D | LMS daemon startup 阶段 |
LmsDrain | spec-2.18 §Q12 D | LMS daemon drain 阶段 |
LmsIdle | spec-2.18 §Q12 D | LMS daemon 等 work_queue wake |
LmdStartup | spec-2.19 §Q12 D | LMD daemon startup 阶段 |
LmdScan | spec-2.19 §D12 + spec-2.20 §I9 (semantic fill) + spec-2.22 §D2 | LMD Tarjan SCC scan 进行中 |
LmdIdle | spec-2.19 §Q12 D | LMD daemon 等 submission counter wake |
LmdProbe | spec-2.22 §D6 | handler 处理 DEADLOCK_PROBE 消息 |
LmdProbeCollect | spec-2.23 §D8 | coordinator 收齐 PROBE REPORT 等待 |
| 事件名 | Spec 来源 | 说明 |
|---|---|---|
ClusterFenceBackendInterruptCheck | spec-2.28 §D9 | backend 在 ProcessInterrupts 内 check freeze flag 期间(~1 μs;留 hook 让 perf 视图能识别 freeze-induced abort 来源) |
这 23 个 Stage 2 事件加上 Stage 1 已 ship 的 BgProc / SharedFs / StartupPhase 类事件,以及 spec-0.11 注册的 46 个设计目标 catalog-only enum,构成了 Stage 2 完结时的 pg_wait_events 总计 66 行(spec-2.29 §D14 baseline)。
设计 taxonomy 的 5 个 Cluster: Reconfig 事件与 Stage 2 ship 的 BgProcLmonReconfigTick 不重叠——前者按"reconfig 业务阶段"细分(GRD rebuild / lock recovery / fence wait / master selection / barrier wait),后者按"LMON tick 执行路径"计时。Stage 5 spec-5.12 实装时,BgProcLmonReconfigTick 的范畴会被设计 taxonomy 5 个事件取代或共存,届时本章会重排。
实时查看当前 backend 等待状态,以及历史累计:
-- 当前所有 backend 的等待事件(PG 原生视图)
SELECT pid, wait_event_type, wait_event, state, query
FROM pg_stat_activity
WHERE wait_event IS NOT NULL
AND wait_event_type LIKE 'Cluster:%'
ORDER BY wait_event_type, wait_event;
-- 按事件聚合的累计计数 + 等待时长(pgrac 新增)
-- Stage 2 期间设计目标事件 calls = 0;Stage 2 wired 事件(§6.13)有真值
SELECT wait_event_type, wait_event,
calls, total_wait_us,
(total_wait_us / NULLIF(calls,0))::int AS avg_us
FROM pg_stat_cluster_wait_events
WHERE wait_event_type LIKE 'Cluster:%'
ORDER BY total_wait_us DESC
LIMIT 20;
-- 时间分桶切片(默认 10s 桶,环形 buffer 保留近 1 小时)
SELECT bucket_start, wait_event, calls, total_wait_us
FROM pg_stat_cluster_wait_events_history
WHERE wait_event = 'IcTcpRecv'
AND bucket_start > now() - interval '10 minutes'
ORDER BY bucket_start;
-- 列出所有可用等待事件(PG 原生,自动包含 catalog-only 设计目标 + Stage 2 wired)
SELECT type, name, description
FROM pg_wait_events
WHERE type LIKE 'Cluster:%'
ORDER BY type, name;
Stage 2 期间典型诊断流程:先在 pg_stat_activity 看实时分布——当前出现的事件名应来自 §6.13 的 23 个(设计 taxonomy 的 46 个 calls 恒为 0);若发现 WAIT_EVENT_GES_* / WAIT_EVENT_PCM_* 等 Stage 0 catalog-only 事件实时出现,意味着某个 spec 越界提前 wire——应回查 spec drafting 流程。
BgProcLmonReconfigTick 的协议背景docs/wait-events-design.md — 完整 46 事件 taxonomy、时序图、告警阈值、Wait Event ID 分配docs/stage2-6-detailed-spec-roadmap.md — 每个 Stage 的 spec 列表(本章 Stage 标签的依据)docs/spec-drafting-lessons.md §L62 / §L13 — wait-event-registration ≠ runtime 反模式(本章为何标注 Stage 0 catalog-only)