PostgreSQL 博览 2026-05-06 RSS 订阅

Figma 讲了为什么在 Postgres 前面换掉 PgBouncer：单线程带来纵向扩展上限、没有负载优先级、缺少 CoDel 之类的背压、连接抖动时容易压垮数据库。替代品 PGKeeper 用 Go 写成，基于 pgx，对外走 gRPC，部署在 NLB 后面，按优先级准入并用欠债机制照顾高优先级流量，配合自适应 LIFO 队列。单实例峰值超过 45000 QPS，上线后数据库 SLO 保持在 99.99% 以上。项目没有开源。

Daniel Gustafsson 推送了 0001 到 0003 三个补丁，收尾在运行中的集群里切换数据校验和这项功能。这批补丁针对的是 Ayush Tiwari 等人此前报告并复现的缺陷，推送前又做了小幅调整，Ayush 确认 v3 解决了他测试中遇到的问题。前几天暴露的成本限制参数失效、对 unlogged 关系多写 WAL、init fork 在恢复期仍需 WAL 才能保住备库一致，都在这一轮里处理掉了。

Alexander Korotkov 给 pg_control 写入的竞态提了个更简单的解法。问题在于后端进程要在挂上共享内存之前读 pg_control。Thomas Munro 此前提议通过 BackendParameters 传一份原型控制文件副本，被指出有用到过期数值的风险。Korotkov 发现挂共享内存之前真正需要的只有 data_checksum_version 一个字段，补丁便只传这个值，也压低了读到陈旧数据的概率。

PostgreSQL 19 把 MultiXactOffset 从 32 位扩到 64 位，pg_upgrade 时会自动重写 pg_multixact/offsets，生产规模的集群可能要几分钟。这消掉了一类紧急事故：MultiXactId 还有余量、成员空间却先耗尽，报 multixact members limit exceeded，逼着在写入高峰做紧急 vacuum。外键密集的多租户系统受益最大。

Yugabyte 的 Mark Peacock 写了一种用 PostgreSQL 顾问锁替代可序列化隔离来防写偏斜的做法，场景是按保留期归档清理数据。传统做法靠分区管理来做保留清理，代价是分区维护的开销；改用顾问锁之后写入性能可预测，清理过程也更好控制。他把这归为数据建模层面的方案：既保住一致性，又不用背分区管理的复杂度，适合保留策略严格、写吞吐又高的应用。

Redis 发布安全公告，一次列出 CVE-2026-23479、CVE-2026-25243、CVE-2026-25588、CVE-2026-25589 和 CVE-2026-23631，同日 GitHub 上出现 7.2.14、7.4.9、8.2.6、8.4.3、8.6.3 五条对应发布。Redis 通常压在缓存、会话、队列和限流路径上，补丁拖着不打会放大暴露面。核对范围不能只看生产主集群，镜像基线和测试环境都要过一遍。

DENIC 通报其 DNS 服务发生中断，带 DNSSEC 签名的 .de 域名可达性受影响，HN 上的讨论积到七百多分，集中在解析链路、DNSSEC 运维复杂度以及要不要临时关掉验证的取舍。顶级域一级的 DNSSEC 事故会跨越单站点、单云和单 ISP，影响面比普通宕机更难隔离。依赖 .de 域名的服务应回头检查外部健康检查是否覆盖 DNSSEC 验证，内部解析器有没有可审计的临时降级策略。