PostgreSQL 博览 2026-08-03 RSS 订阅

级联备库做完归档恢复再连回上游时会永久失败，报「请求的起始位置超前于本服务器的 WAL 刷写位置」。原因是归档恢复按整段处理 WAL，备库的下一个读取位置正好落在段边界上，机械地超前于上游刷写点，而这里没有重试。缺陷自 9.3 起就在，传统部署很少搭出这种拓扑，CloudNativePG 用 YAML 几分钟就能组合跨区流复制与归档回退，于是稳定复现。修复随 18.5、17.11、16.15、15.19 和 14.24 发布。

两种故障在应用日志里长得很像，处置方向却相反。Umair Shahid 给出判据：真卡住时连新开的会话都进不去，包括直接在机器上跑的 psql，根因多在数据库之下的内存、存储或 CPU；连接过期则是池里的连接报 connection reset by peer，而新建连接立刻成功，问题在网络路径。排查顺序是先在主机本地直连，再对比池化与新建连接，查日志里的重置记录，最后看 pg_stat_activity 里那个后端是否为 idle。

两个属于「更多代码路径改用流式读」系列的提交，凑在一起会出问题。Mihail Nikalayeu 报告，其中一个提交缓存了元页指针，而 hashbulkdelete() 里调用 read_stream_begin_relation() 可能让它失效：调用链经表空间查找触发系统表扫描，进而处理失效消息并释放已缓存的指针，最终引用到无效的块号。他给出的修复只需重排少量代码，同时建议考虑更普遍的防护。该缺陷只影响主干。

把 MCP 接进数据库，等于把 agent 身份、工具调用和数据权限并到同一个暴露面。ArcadeDB 把 26.7.3 定为 26.7.2 的定向热修复，处理内部审计发现的 MCP 传输层认证主体绑定与信息泄露、触发器授权，并修掉 26.7.2 在超级节点边追加时的数据丢失回归。GitHub 安全公告库本窗口补入了对应记录，但缺少完整版本范围。开启 MCP 或使用高阶图的部署应以 26.7.3 为最低核查线。