PG 切换卡住, 这个 bugfix 可能救你一次

PostgreSQL 这个 bug 修复，可能救你一次

阅读需要 3 分钟

先问一个问题

你的数据库有没有遇到过这种情况：

主库突然故障，需要把备库"升职"成主库，结果等了十几秒、甚至几十秒都没动静？

如果你觉得"还行吧，等就等"，那你可能不知道——这几十秒里，你的业务已经瘫痪了。

今天聊的这个问题，在 bugfix 之前，可能正在悄悄拖垮你的主备切换速度。

备库晋升为什么会"卡住"？

先科普一下背景。

PostgreSQL 从 17 开始支持逻辑复制槽同步——简单说就是备库可以自动同步主库的复制槽定义，不用手动维护两份。

这个功能靠一个后台 worker 定期工作：

主库 ←→ slotsync worker（备库）

问题出在哪呢？

当备库要晋升成主库时，需要先把这个 worker 停掉。

以前的方式是：发一个 SIGUSR1 信号给 worker，让它退出。

听起来没问题？

但如果当时 worker 正在等主库响应（比如网络抖动、网线松了），它就卡在那儿了——SIGUSR1 根本叫不醒它。

结果就是：整个晋升流程被阻塞，业务眼睁睁看着数据库"假死"。

PostgreSQL 怎么修的？

核心改动就一件事：换信号。

不再用通用的 SIGUSR1，而是用专门的 PROCSIG_SLOTSYNC_MESSAGE 信号。

新信号配合 PostgreSQL 的中断机制，效果是这样的：

晋升触发
    ↓
发送专用信号
    ↓
信号处理器设置"中断标志"
    ↓
下次 CHECK_FOR_INTERRUPTS 立即响应
    ↓
worker 立即退出 ✓

30 秒的等待 → 瞬间完成

这不比等网络超时爽多了？

修复前 vs 修复后

你品，你细品。

对你意味着什么？

1. 主备切换更可靠

不会再出现"晋升卡住、只能强制 kill"的尴尬场面。

2. 故障恢复更快

关键时刻早恢复一秒，业务少损失一分。

3. 运维更省心

晋升操作可预测，不用提心吊胆等超时。

一句话总结

PostgreSQL 用一个专用信号 + 中断机制，解决了备库晋升时被 slotsync worker 阻塞的问题。

这个改动不大，但关键时刻能救命。