www.876873.xyz

🛑 物理前置条件：悬崖勒马的默认设置（pause）

• 隐蔽的参数：在 PostgreSQL（尤其是 PG 12 及以后的版本）中，当你配置了恢复目标（比如 recovery_target_time = '15:00:00'）时，有一个极其关键的隐蔽参数叫 recovery_target_action。
• 默认的底线：它的默认值是 pause（暂停）。
• 发生什么了？ 当 Startup 进程重放日志刚好到达下午 3 点时，它不会立刻去做 Checkpoint，也不会立刻切换时间线，更不会立刻删除 recovery.signal！
• 悬崖停滞：它会踩下刹车，把底层物理状态死死卡住。此时，数据库处于一种**“挂起（Paused）的只读热备状态”**。

🕵️‍♂️ 人类介入阶段：战术核验（为什么需要暂停？）

为什么内核要傻傻地停在这里？这是为了给你（DBA）留出“后悔”的时间！

• 验证数据：此时，业务虽然写不进来，但你可以用 psql 连入数据库（前提是 hot_standby = on）。
• 人工查验：你可以执行 SELECT * FROM 被删的表; 亲眼看看，下午 3 点的数据到底是不是你想要的？
• 抉择时刻：
  • 如果发现不对（恢复早了或晚了）：你可以直接关闭数据库（pg_ctl stop），修改配置文件里的目标时间，重新启动恢复！因为此时时间线还没切换，你随时可以反悔！
  • 如果确认无误（数据完美）：这就是你掏出那把终极钥匙的时刻了！

🚀 终极指令：select pg_wal_replay_resume();

当你在终端里敲下这句命令并敲击回车，你实际上是在对底层被挂起的 Startup 进程大喊：“指挥官已确认时空坐标无误！解除暂停！执行终极跃迁！”

这行命令触发的底层物理动作（微秒级连环爆炸）：

1. 唤醒：底层的 Startup 进程瞬间从休眠状态（WaitLatch）中被唤醒。
2. 终极加固：立刻执行我们之前讲过的 End-of-Recovery Checkpoint（强制把脏页砸进硬盘）。
3. 计算死神坐标：算出 %r 边界文件，触发 archive_cleanup_command 删垃圾。
4. 时空切割：生成 .history 文件，时间线 ID 正式 +1。
5. 拔掉物理锁：删除 $PGDATA/recovery.signal。
6. 开门迎客：通知 postmaster 进程，彻底解除 5432 端口的写保护。新宇宙正式诞生！