PostgreSQL 博览 2026-09-19 RSS 订阅

PostgreSQL 修复了 SQL/JSON 查询函数传递大文本时可能读到错误内容的问题。此前，PASSING 把文本值直接交给 JSON 路径执行器，遇到由 TOAST 保存的外部数据时，没有先还原实际文本。新提交统一先解包文本，并增加压缩及外部存储两种回归用例。修复已进入主干及 17、18、19 分支；依赖 JSON 查询处理大字段的应用，可据此补充输入与输出一致性测试，后续升级仍应以正式维护版本为准。

Inngest 披露了一起由账户删除引发的 PostgreSQL 故障：单个事务沿外键级联清理数十张表，随后重复请求排队等锁，占住共享 PgBouncer 的客户端槽位，连接数升至平时约 14 倍。重启连接池没有解除阻塞，取消删除事务后才逐步恢复，部署止损开关时又出现第二轮影响。团队正改用软删除，并把必要的硬删除拆成限速、去重的后台批次；复盘也强调，数据库锁释放后，连接池积压仍可能延长业务恢复。

微软分享了跨数据库迁移后吞吐下降的排查案例：高并发下，一条 NOT IN 子查询反复扫描物化结果，增加硬件只能带来有限改善。确认业务所需的空值语义后，改写为 NOT EXISTS 或左连接反查，再补上以关联键开头的复合索引，才把整表扫描变成少量索引探测。厂商称，在给出的 64 客户端合成复现实验中，吞吐提升超过 800 倍。案例的关键是分别验证计划形态和访问路径，避免把单独加索引无效误判成索引本身无用。

AWS 给出 Aurora PostgreSQL 与 Valkey 的三层成员查询方案：Bloom 过滤器挡住大量不存在的键，精确缓存承接命中，数据库保留权威数据。文章特别区分了过滤器自身的误报率与数据库提交后的传播延迟：新记录尚未进入过滤器时，仍可能被错误判为不存在。因此，方案要求近期写入保护、持久化重试和缓存失效机制，并让最终确认读取具有写后可读保证的数据源。删除通过失效缓存及定期重建清理，性能收益取决于负查询比例与同步机制。

Percona 展示了 MySQL Operator 的跨集群灾备部署：两个站点各自运行 Group Replication，通过 ClusterSet 在站点之间建立异步复制。Operator 负责引导灾备集群、克隆初始数据并维护复制关系；大数据集也可先从备份恢复，再追赶增量。文章演示了计划切换后主备角色互换，以及应用通过代理连接新主节点的流程。这种结构把站内高可用与站间灾备分开处理，部署时仍需验证网络、凭据、数据追赶和故障切换行为。

Cloudflare 复盘了 Pingora 后端路由器的一致性哈希优化。服务器权重和功能组合生成了大量哈希环，团队先将每个哈希点从 8 字节压缩到 6 字节，再用统计分析发现，继续增加虚拟节点收益递减，32 位哈希碰撞还会抵消均衡效果。减少约九成哈希点后，团队同时保留新旧环，按请求和数据中心逐步迁移，避免缓存大面积失效冲击源站。厂商称，这轮改造在全球回收超过 100 TB 内存，相关能力已进入 pingora-ketama。