-- 1. 快速确认连接数和状态分布
SELECT state, count(*) AS cnt
FROM pg_stat_activity
GROUP BY state ORDER BY cnt DESC;

-- 2. 定位可疑连接：同时 active 且运行时间异常
SELECT pid, usename, application_name, state,
       wait_event_type, wait_event,
       now() - xact_start AS txn_duration,
       now() - query_start AS query_duration,
       query
FROM pg_stat_activity
WHERE state = 'active'
  AND now() - query_start > interval '10 seconds'
ORDER BY query_start;

-- 3. 如果有 pg_stat_statements，找出 memory 消耗最高的 query
-- 用 temp_bytes 做 proxies（需要 track_io_timing=on + PG 16+）：
SELECT queryid, calls,
       mean_exec_time::numeric(10,1) AS avg_ms,
       (temp_blks_read + temp_blks_written) * 8192 / calls AS avg_temp_bytes_per_call,
       LEFT(query, 200) AS query_preview
FROM pg_stat_statements
WHERE calls > 0
ORDER BY (temp_blks_read + temp_blks_written) * 8192 / calls DESC
LIMIT 10;
-- 高 temp_bytes 意味着查询使用了磁盘临时文件（work_mem 不够）
```bash

### 1.5 修复边界

| 操作 | 效果 | 边界 |
|------|------|------|
| `ALTER SYSTEM SET work_mem = '2MB'` + `pg_reload_conf()` | 降低单操作内存，给现有连接腾空间 | 对已在执行的查询不生效；太小会导致 sort 频繁写 temp file |
| `SELECT pg_terminate_backend(pid)` | 杀掉特定 Backend | 被杀的连接无法重做未提交事务；如果所有连接都在执行同一条业务查询，杀完还会重来 |
| `ALTER SYSTEM SET max_connections = 'X'` + restart | 限制连接数上限 | 需要重启；太小会导致连接排队，应用端必须设 `connect_timeout` |
| `ALTER DATABASE db SET statement_timeout = '30s'` | 防止单个查询无限跑 | 只影响新连接 |
| 应用层加连接池限流（`pgbouncer` transaction pooling） | 将 200 个应用连接映射到 20 个 PG 连接 | 需要部署 pgbouncer；`SET` 语句和 prepared statement 在 transaction pooling 下有约束 |

将 `work_mem` 从默认 4MB 调到 2MB 并不是万能的——真正需要 4MB 的 hash join 会溢出到 temp file，造成新的 I/O 瓶颈。正确做法是同时调整 `hash_mem_multiplier`：
```sql
-- PG 15+: 降低 hash join 的额外内存权重
ALTER SYSTEM SET hash_mem_multiplier = 1.0;
ALTER SYSTEM SET work_mem = '4MB';
SELECT pg_reload_conf();

-- 连接使用率（与 max_connections 的比值）
-- 告警阈值：> 80%
SELECT count(*) * 100.0 / current_setting('max_connections')::int AS pct_conn_used
FROM pg_stat_activity;

-- 有 temp_file 写入的查询占比
-- 告警阈值：> 10%
SELECT count(*) FILTER (WHERE temp_blks_written > 0) * 100.0 / count(*) AS pct_with_temp
FROM pg_stat_statements WHERE calls > 0;

-- OS 内存水位
-- 告警阈值：MemAvailable < 10% 总内存
-- 用 cron + grep /proc/meminfo，或 node_exporter + Prometheus
```text

---

## 二、事务 ID wraparound 危机完整时间线

### 2.1 现象

某天凌晨，所有写操作突然报错：

// src/backend/access/transam/varsup.c, SetTransactionIdLimit()
#define XID_WRAP_LIMIT     1000000  // 100 万，之后数据库进入只读
#define XID_STOP_LIMIT    10000000  // 1000 万，之后发出警告但允许写入

void SetTransactionIdLimit(TransactionId oldest_datfrozenxid, Oid oldest_datoid) {
    // xidWrapLimit = oldest_datfrozenxid + (MaxTransactionId >> 1) - XID_WRAP_LIMIT
    // xidStopLimit = oldest_datfrozenxid + (MaxTransactionId >> 1) - XID_STOP_LIMIT
}
```bash

### 2.3 时序推演

```mermaid
sequenceDiagram
    participant App as 应用写入
    participant AV as Autovacuum Worker
    participant Cat as pg_catalog
    participant Xid as XID 分配器
    participant Prot as Wraparound 保护

    Note over App,Prot: T0: 正常运作，age(relfrozenxid) 缓慢增长
    App->>Cat: UPDATE/DELETE 频繁
    Cat->>Cat: dead tuple 堆积，age(relfrozenxid) 增加
    AV->>Cat: autovacuum 正常触发，但 cost_delay 太高
    Note over AV: VACUUM 跟不上 dead tuple 产生速度

    Note over App,Prot: T1: 跨过 autovacuum_freeze_max_age (2 亿)
    AV->>Cat: anti-wraparound VACUUM 强制触发
    Note over AV: pg_stat_activity: "VACUUM (to prevent wraparound)"
    AV-->>Cat: 大表扫描 + index cleanup 耗时数小时

    Note over App,Prot: T2: anti-wraparound VACUUM 被取消或卡住
    App->>Cat: DDL 持锁 → autovacuum 等锁
    Note over AV: autovacuum 多次被 lock_timeout 取消
    Xid->>Xid: age(relfrozenxid) 继续增长

    Note over App,Prot: T3: xidStopLimit 触发 (1000 万)
    Prot->>App: WARNING: database must be vacuumed within 10000000 transactions

    Note over App,Prot: T4: xidWrapLimit 触发 (100 万)
    Prot->>App: ERROR: database is not accepting commands to avoid wraparound
    Note over App: 数据库进入只读 shutdown 状态

-- 第一步：查看全库最危险的 age
SELECT datname, age(datfrozenxid) AS age_xid,
       pg_size_pretty(pg_database_size(datname)) AS db_size
FROM pg_database
ORDER BY age(datfrozenxid) DESC;

-- 第二步：找出具体拖后腿的表和数据库
SELECT c.oid::regclass AS table_name,
       age(c.relfrozenxid) AS age_xid,
       pg_size_pretty(pg_total_relation_size(c.oid)) AS table_size,
       n.nspname AS schema
FROM pg_class c
JOIN pg_namespace n ON c.relnamespace = n.oid
WHERE c.relkind IN ('r', 't', 'm')  -- 普通表、toast 表、物化视图
  AND age(c.relfrozenxid) > 100000000  -- 1 亿，重点关注
ORDER BY age(c.relfrozenxid) DESC
LIMIT 20;

-- 第三步：检查 autovacuum 到底在干什么
SELECT pid, datname, usename, backend_start,
       now() - backend_start AS running_for,
       query
FROM pg_stat_activity
WHERE backend_type = 'autovacuum worker'
ORDER BY backend_start;

-- 第四步：看当前 anti-wraparound 的进度（PG 14+）
SELECT p.datname, p.relid::regclass,
       p.phase,
       p.heap_blks_total, p.heap_blks_scanned,
       CASE WHEN p.heap_blks_total > 0
            THEN round(100.0 * p.heap_blks_scanned / p.heap_blks_total, 1)
            ELSE 0 END AS pct_scanned,
       p.index_vacuum_count, p.max_dead_tuple_bytes
FROM pg_stat_progress_vacuum p
WHERE p.phase IS NOT NULL;
```bash

### 2.5 修复边界

数据库已经进入只读 shutdown 时，只有两条路：

**路径 A：单用户模式 VACUUM（标准方案）**

```bash
# 1. 停掉 PG
pg_ctl stop -D $PGDATA

# 2. 单用户模式启动（不启动 postmaster，不监听端口）
postgres --single -D $PGDATA dbname

# 3. 在 single-user 提示符下执行
VACUUM FREEZE;
-- 或者针对特定表
VACUUM (FREEZE, VERBOSE) the_problem_table;

# 4. 退出（Ctrl+D），正常启动
pg_ctl start -D $PGDATA

-- 在进入 shutdown 之前可以用，但已经 shutdown 了就无效
ALTER SYSTEM SET autovacuum_freeze_max_age = 2000000000;  -- 20 亿
SELECT pg_reload_conf();
```text

- **风险巨大**：如果 age 确实已经到了 20 亿附近，取消保护意味着 tuples 可能变成不可见——数据没有物理删除，但查询看不到。唯一恢复手段是单用户模式 VACUUM FREEZE。
- **适用**：仅在 age 离真实 wraparound 还有很大差距、但保护阈值触发过早时作为临时放开手段。

**路径 C：预防——永远别到这里**

确保以下检查在 age 到 1 亿之前就触发告警：

```sql
-- 监控查询：放在 cron 里每小时跑一次
SELECT datname, age(datfrozenxid),
       CASE WHEN age(datfrozenxid) > 150000000 THEN 'CRITICAL'
            WHEN age(datfrozenxid) > 100000000 THEN 'WARNING'
            ELSE 'OK' END AS status
FROM pg_database;

// src/backend/replication/slot.c, GetOldestSafeRestartLSN()
// 遍历 pg_replication_slots，找到最老的 restart_lsn
// 这个 LSN 即为 WAL 回收的"安全边界"
// 如果某个 slot 的 restart_lsn 非常老，所有 WAL 段都不能回收
```text

`wal_keep_size` 和 slot 的关系经常被误解：它们不是"取最大值"，而是**叠加**。`wal_keep_size` 说"至少保留 X MB 的 WAL"，slot 说"不管 X 是多少，restart_lsn 之前的都要保留"。如果 slot 的 restart_lsn 比 `wal_keep_size` 覆盖的范围更老，slot 的约束生效，保留下来的 WAL 会远超 `wal_keep_size`。

多米诺效应：

1. Standby 因网络、磁盘或进程问题宕机。
2. Primary 上的 slot 状态变为 `active = false`（因为 WAL Sender 进程断开），但 `restart_lsn` 停在上次 standby 确认的位置。
3. Primary 继续接受写入，WAL 持续产生，但因为 slot 不推进，旧 WAL 段无法回收。
4. `pg_wal` 目录开始膨胀。`wal_keep_size` 不限制 slot 保留的 WAL。
5. 磁盘满 → Primary 无法继续写 WAL → PANIC → crash。
6. 重启后磁盘仍满，PG 无法写 WAL 进入 recovery → 无法启动。

### 3.3 时序推演

```mermaid
sequenceDiagram
    participant Primary as Primary
    participant Slot as Replication Slot
    participant WAL as pg_wal 目录
    participant Disk as 磁盘
    participant Standby as Standby

    Note over Primary,Standby: T0: 正常复制
    Standby->>Primary: 确认消费到 LSN = 0/30000000
    Primary->>Slot: 更新 restart_lsn = 0/30000000
    Primary->>WAL: 回收 0/30000000 之前的 WAL 段

    Note over Primary,Standby: T1: Standby 宕机
    Standby--xPrimary: 连接断开
    Slot->>Slot: active = false, restart_lsn 冻结在 0/30000000

    Note over Primary,Standby: T2: Primary 持续写入
    Primary->>WAL: 新 WAL: 0/30000000 → 0/50000000 → 0/A0000000
    Primary-->>WAL: 尝试回收旧段 → 被 slot 阻止
    Disk->>Disk: pg_wal 持续增长: 500MB → 2GB → 10GB

    Note over Primary,Standby: T3: 磁盘满
    Primary->>WAL: 申请新 WAL 段
    WAL-->>Primary: 磁盘空间不足
    Primary->>Primary: PANIC: could not write to WAL
    Note over Primary: 数据库 crash

    Note over Primary,Standby: T4: 尝试重启
    Primary->>Primary: 启动 → 需要写 WAL → 磁盘满 → 失败
    Note over Primary: 死锁：需要删文件腾空间，但删 WAL 可能丢掉未归档的数据

-- 第一步：查看所有 slot 的状态，重点关注 active=f 且 restart_lsn 落后很多的
SELECT slot_name, slot_type, database, active,
       pg_size_pretty(pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn)) AS behind,
       restart_lsn,
       CASE WHEN active = false AND pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) > 1073741824
            THEN 'DANGER'  -- 落后 1GB 以上
            WHEN active = false THEN 'WARNING'
            ELSE 'OK' END AS status
FROM pg_replication_slots
ORDER BY pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) DESC;

-- 第二步：检查 pg_wal 目录的实际占用
SELECT pg_size_pretty(sum(size)) AS pg_wal_size
FROM pg_ls_waldir();

-- 第三步：确认磁盘剩余空间
--（需要在 OS 层执行 df -h $PGDATA/pg_wal，或者用 pg_ls_dir 间接观察）
```bash

### 3.5 修复边界

| 场景 | 操作 | 后果 |
|------|------|------|
| Standby 可恢复（临时网络故障） | 修复网络/重启 standby → 它会自动重连 → slot restart_lsn 推进 → WAL 自动回收 | 无需操作 |
| Standby 永久性不可恢复（硬件损坏） | `SELECT pg_drop_replication_slot('slot_name')` | 删除 slot。后果：必须重建 standby（重新 pg_basebackup），因为删掉的 WAL 可能包含 standby 需要的记录 |
| 磁盘已满但还没 crash | 立即 `pg_drop_replication_slot()` → 等 checkpoint 回收 WAL | 如果 slot 是 sync standby 的，删除意味着放弃同步复制保护 |
| 磁盘已满且已 crash | OS 层排查：确认 `pg_wal` 是否真的占满 → 如果有未归档 WAL，手动 `pg_waldump` 确认内容 → 决定是删 WAL 腾空间还是先 dd 到其他盘 | `pg_resetwal` 可以清空 WAL 重启，但代价极大（见第 24 章） |

**关键决策点**：删除 replication slot 之前，必须确认 standby 是否还在用这个 slot。如果 standby 只是临时不可用但很快会恢复，删掉 slot 意味着必须重做 base backup——这是一个数小时的操作，取决于数据量。

### 3.6 监控埋点

```sql
-- slot 落后 WAL 超过 1GB 的报警
-- 放在 cron 每分钟跑
SELECT slot_name,
       pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) AS lag_bytes
FROM pg_replication_slots
WHERE pg_wal_lsn_diff(pg_current_wal_lsn(), restart_lsn) > 1073741824;

-- pg_wal 磁盘占大盘百分比（需要 OS 层配合）
-- node_exporter + disk usage alert on $PGDATA/pg_wal

// src/backend/postmaster/postmaster.c, HandleChildCrash()
// 关键逻辑：
// 1. 确定 pmdie 模式（是否正在 shutdown？如果 crash 发生在 shutdown 期间，不 restart）
// 2. 如果 restart_after_crash=on → FatalError = true → 进入 PM_RUN 重新初始化
// 3. FatalError = true 时，所有 Backend 在下一次 ReadCommand() 时检查并退出
```bash

### 4.3 时序推演

```mermaid
sequenceDiagram
    participant App as 应用
    participant BE as Backend (大查询)
    participant PM as Postmaster
    participant OS as Linux OOM Killer

    Note over App,OS: 状态：100 个连接，其中 1 个执行复杂 hash join
    BE->>BE: hash join build 阶段申请 work_mem × hash_mem_multiplier
    BE->>OS: 多次 malloc，累计 500MB+
    Note over OS: 系统空闲内存不足
    OS->>BE: OOM Killer 选中此 Backend (oom_score 高)
    OS->>BE: SIGKILL
    BE--xPM: 子进程异常退出
    PM->>PM: SIGCHLD → reaper() → HandleChildCrash()
    PM->>PM: restart_after_crash=on → 标记 FatalError=true
    PM->>App: 给所有剩余 Backend 发 SIGQUIT
    App--xPM: 200 个连接全部断开
    PM->>PM: 重新 InitPostgres → fork 辅助进程
    Note over App,OS: PG 重新可用，但所有连接需重建
    App->>PM: 连接池自动重连
    App->>BE: 再次执行相同查询
    Note over App,OS: 如果 work_mem 配置没变 → 再次 OOM → 循环

-- 第一步：确认 crash 后 PG 状态
SELECT pg_postmaster_start_time();  -- 如果时间很近，说明刚 restart

-- 第二步（如果 PG 已恢复）：找出内存消耗大户
-- 需要 pg_stat_statements 有足够历史
SELECT queryid,
       calls,
       mean_exec_time::numeric(10,1) AS avg_ms,
       (shared_blks_dirtied + local_blks_dirtied) * 8192 / calls AS avg_dirty_bytes_per_call,
       (temp_blks_read + temp_blks_written) * 8192 / calls AS avg_temp_bytes_per_call,
       LEFT(query, 150)
FROM pg_stat_statements
WHERE calls > 10
ORDER BY (temp_blks_read + temp_blks_written) * 8192 / calls DESC
LIMIT 10;

-- 第三步：确认当前配置
SHOW work_mem;
SHOW hash_mem_multiplier;
SHOW maintenance_work_mem;
SHOW shared_buffers;
SHOW max_connections;

-- 第四步：事后查 OS 日志（在 shell 中执行）
-- dmesg | grep -i "killed process"
-- journalctl -u postgresql --since "1 hour ago"
```bash

### 4.5 修复边界

| 操作 | 效果 | 边界 |
|------|------|------|
| 降低 `work_mem` + `hash_mem_multiplier` | 减少单个查询的峰值内存 | 可能导致 temp file 增多，I/O 升高 |
| 降低 `max_connections` | 减少并发连接数，降低乘法效应 | 需要重启；太小导致连接排队 |
| 增加物理内存 / swap | 提高系统内存总量 | 硬件升级；swap 太慢不能替代真实内存 |
| 查询优化：替换 hash join 为 nestloop（对于小表） | 避免 hash table 的大内存分配 | 需要确认 nestloop 确实不慢；可能需要 hint 或 session 级 `SET enable_hashjoin = off` |
| `ALTER USER app_user SET statement_timeout = '30s'` | 防止单个查询跑太久 | 也会超时 kill 正常的长报表查询 |
| 部署 pgbouncer（transaction pooling） | 减少 PG 实际连接数 | 见第 1 节的边界 |

**关于 `restart_after_crash`**：关了它（`ALTER SYSTEM SET restart_after_crash = off`）可以防止 OOM kill 后的连锁 restart——但代价是：如果 PG crash 了，它不会自己起来，你需要手动启动。生产环境通常保留 `on`，但搭配进程监控（systemd `Restart=on-failure`）作为双重保险。

---

## 五、长事务（idle in transaction）的隐性破坏

### 5.1 现象

症状分散、隐蔽，但共同指向一个根因：

- 凌晨 3 点跑 `ALTER TABLE ... ADD COLUMN` 的 DDL hang 住，永远不返回。
- 表在膨胀——`pg_stat_user_tables.n_dead_tup` 持续增长，但 autovacuum 正常触发，VACUUM 也正常完成。
- `pg_stat_activity` 里有一个 `idle in transaction` 状态的连接，已经存在了 8 小时。

### 5.2 根因

PG 的 `idle in transaction` 是一个很容易被忽略但破坏力极强的状态——它和 `idle`（正常空闲连接）不同：

- **`idle`**：连接在事务中没有执行任何 DML，或者事务已经提交。实际上连接完全空闲，不会阻塞 VACUUM。
- **`idle in transaction`**：连接已经执行了至少一条 DML（例如 `SELECT * FROM t WHERE id = 1`），事务还没有 `COMMIT` 或 `ROLLBACK`。此时连接持有快照（snapshot），持有表级或行级锁。

长事务的两种破坏路径：

**路径一：VACUUM 无法回收 dead tuple**

VACUUM 回收 dead tuple 的核心判断是：**这个 dead tuple 对于所有现存事务是否都是不可见的？** 如果连接 A 的事务开始于 8 小时前，它持有的快照只包含 8 小时前已提交的数据。那么这 8 小时内产生的所有 dead tuple——即使 `xmax` 的事务早已提交——对连接 A 的快照来说，仍然是应当可见的旧版本。VACUUM 必须保留它们。

```c
// src/backend/access/heap/vacuumlazy.c, lazy_scan_heap()
// 对所有 dead tuple 调用 HeapTupleSatisfiesVacuumHorizon()
// 如果 dead tuple 的 xmax 比任何现存事务的 xmin 更新，不能回收
// OldestXmin = 所有活跃事务 + idle in transaction 的最小 xmin

-- 可以用这个查询直观看到锁等待链：
SELECT blocked.pid AS blocked_pid,
       blocked.query AS blocked_query,
       blocking.pid AS blocking_pid,
       blocking.query AS blocking_query,
       blocking.state AS blocking_state,
       now() - blocking.xact_start AS blocking_txn_age
FROM pg_stat_activity blocked
JOIN pg_locks blk_l ON blocked.pid = blk_l.pid AND NOT blk_l.granted
JOIN pg_locks blg_l ON blk_l.locktype = blg_l.locktype
                    AND blk_l.database = blg_l.database
                    AND blk_l.relation = blg_l.relation
                    AND blg_l.granted
JOIN pg_stat_activity blocking ON blg_l.pid = blocking.pid
WHERE blocked.wait_event_type = 'Lock';
```bash

### 5.3 时序推演

```mermaid
sequenceDiagram
    participant User as 用户 A
    participant TXN as 长事务连接
    participant App as 应用写入
    participant VAC as Autovacuum
    participant DBA as DBA (DDL)

    Note over User,DBA: T0: 用户 A 在 psql 中开启事务并读取
    User->>TXN: BEGIN; SELECT * FROM orders LIMIT 1;
    TXN->>TXN: 获取 AccessShareLock on orders
    TXN->>TXN: 创建 snapshot (xmin = 1000000)
    Note over TXN: 用户离开座位，事务保持 "idle in transaction"

    Note over User,DBA: T0+1h: 应用正常读写
    App->>TXN: UPDATE orders SET status = 'shipped' WHERE id = 42
    App->>App: COMMIT（生成 dead tuple）
    VAC->>TXN: autovacuum: 尝试回收 dead tuple
    TXN-->>VAC: OldestXmin = 1000000 (长事务的 xmin)
    Note over VAC: 无法回收 xmin > 1000000 之后的 dead tuple

    Note over User,DBA: T0+8h: DBA 执行 DDL
    DBA->>TXN: ALTER TABLE orders ADD COLUMN note TEXT;
    DBA->>DBA: 需要 AccessExclusiveLock
    DBA-->>DBA: 排队等锁（长事务持有 AccessShareLock）
    Note over DBA: DDL hang 住，后续读查询也排队

    Note over User,DBA: T0+8h+5min: 排查
    DBA->>DBA: SELECT * FROM pg_stat_activity WHERE state='idle in transaction'
    DBA->>DBA: SELECT pg_terminate_backend(长事务 pid)

    Note over VAC: VACUUM 可以继续、DDL 获得锁、膨胀开始修复

-- 第一步：找出所有 idle in transaction 状态且超过一定时长的连接
SELECT pid, usename, application_name, client_addr,
       state, now() - xact_start AS txn_age,
       now() - state_change AS state_age,
       wait_event_type, wait_event,
       query
FROM pg_stat_activity
WHERE state = 'idle in transaction'
  AND now() - xact_start > interval '5 minutes'
ORDER BY xact_start;

-- 第二步：看长事务持有哪些锁
SELECT l.pid, l.locktype, l.database, l.relation::regclass AS locked_table,
       l.mode, l.granted,
       a.state, now() - a.xact_start AS txn_age,
       a.query AS last_query
FROM pg_locks l
JOIN pg_stat_activity a ON l.pid = a.pid
WHERE a.state = 'idle in transaction'
  AND now() - a.xact_start > interval '5 minutes'
ORDER BY a.xact_start, l.relation;

-- 第三步：看是否有 DDL 在等锁
SELECT pid, usename, now() - query_start AS waiting_for,
       wait_event_type, wait_event,
       query
FROM pg_stat_activity
WHERE wait_event_type = 'Lock'
  AND wait_event = 'relation'
ORDER BY query_start;

-- 第四步：追踪完整的锁等待链
SELECT blocked.pid AS blocked_pid,
       blocked.query AS blocked_query,
       blocking.pid AS blocking_pid,
       blocking.query AS holding_query,
       blocking.state AS holding_state,
       now() - blocking.xact_start AS holding_txn_age
FROM pg_stat_activity blocked
JOIN pg_locks blk_l ON blocked.pid = blk_l.pid AND NOT blk_l.granted
JOIN pg_locks blg_l ON blk_l.locktype = blg_l.locktype
                    AND blk_l.database = blg_l.database
                    AND blk_l.relation = blg_l.relation
                    AND blg_l.granted
JOIN pg_stat_activity blocking ON blg_l.pid = blocking.pid;
```bash

### 5.5 修复边界

| 操作 | 效果 | 边界 |
|------|------|------|
| `SELECT pg_terminate_backend(pid)` | 立即终止长事务，释放锁和快照 | 事务回滚：该事务内所有未提交的 DML 丢失。如果 DML 已经持久化到磁盘但所在事务被回滚，这部分变更丢失 |
| `ALTER SYSTEM SET idle_in_transaction_session_timeout = '10min'` | 超过 10 分钟的 idle in transaction 自动断开 | 只影响新连接。需要 `pg_reload_conf()` |
| 应用程序端加事务超时 | 在应用层控制 `SET statement_timeout` 或使用连接池的事务超时 | 需要应用代码配合 |
| 禁止在交互式 psql 中使用 `AUTOCOMMIT=off` | 防止用户忘记 commit | 可能影响需要手动事务的工作流 |
| 检查 ORM 框架的事务管理 | 很多 ORM 默认 `autocommit=false` 且在异常路径中不 rollback | 需检查 Django / SQLAlchemy / Hibernate 等框架的配置 |

**关于 `pg_terminate_backend`**：杀掉长事务后，VACUUM 可以马上回收之前被阻塞的 dead tuple，但已经积累的膨胀不会自动消失——VACUUM 回收空间但不收缩物理文件。如果需要回收磁盘空间到 OS，必须执行 `VACUUM FULL`（会锁表，阻塞读写）或 `pg_repack`（需要扩展，不锁表但需要额外磁盘空间）。

### 5.6 监控埋点

```sql
-- idle in transaction 的持续时间和数量
-- 告警阈值：任何连接 > 15 分钟，或数量 > 5
SELECT count(*) AS idle_in_txn_cnt,
       max(now() - xact_start) AS max_txn_age
FROM pg_stat_activity
WHERE state = 'idle in transaction';

-- 锁等待超过 30 秒的查询
-- 告警阈值：> 0
SELECT count(*) AS lock_waiting_cnt
FROM pg_stat_activity
WHERE wait_event_type = 'Lock'
  AND now() - query_start > interval '30 seconds';