PostgreSQL 博览 2026-05-14 RSS 订阅

PostgreSQL 官方发布 18.4、17.10、16.14、15.18 和 14.23，修复 11 个安全漏洞和 60 多个 bug，其中三个 CVE 的 CVSS 评分为 8.8，覆盖 14 到 18 全部受支持版本。受影响的不止服务端，libpq 客户端工具链、备份恢复工具链、contrib 里的 refint，以及仍在用 MD5 哈希的用户都被点名。官方同时提醒 PostgreSQL 14 将在 11 月结束支持。

CVE-2026-6637 出在 contrib 的 refint 模块上，官方给出 CVSS 8.8，影响 PostgreSQL 14 到 18，漏洞类型包括栈缓冲区溢出和 SQL 注入。很多组织对服务端二进制的补丁很敏感，却容易漏掉 contrib 扩展。除了升级小版本，还要确认库里是否真的装了并启用了 refint，按 release notes 执行必要的扩展更新，托管平台则应扫描用户库的扩展版本。

CVE-2026-6477 出在 libpq 的大对象处理上，CVSS 8.8，影响 PostgreSQL 14 到 18，官方点名了 psql 的 \lo_export 与 pg_dump 的调用路径。常见的安全模型默认客户端连上数据库之后风险主要在服务端，这个漏洞说明连到不可信或已被攻陷的服务器时，客户端工具本身也会成为攻击面。DBA 工作站、CI 里的备份镜像和迁移工具容器都要升级 libpq 与客户端包，只升级服务端不够。

Christophe Pettus 把这次的十一个 CVE 和历史节奏做了对比，认为安全发现的模式可能正在变化：成熟的数据库内核仍然可能被系统化地重新审计一遍，于是修复批量出现。他提醒这次升级不需要 pg_upgrade，但 release notes 要仔细读，特别是与系统表和扩展有关的后续 SQL 操作。运维上的结论是把小版本升级从低优先级的例行维护，改造成可以快速执行的安全流程。

Christophe Pettus 介绍 PostgreSQL 19 里 MERGE PARTITIONS 与 SPLIT PARTITION 的最新设计，重点是锁比之前更简单也更安全。大表的生命周期管理、冷热数据滚动、租户拆分和时间分区重整都依赖分区维护能力，而锁的粒度直接决定这些操作能不能在高并发的生产环境里做。大量使用范围分区和列表分区的系统可以提前跟踪这条路线，评估将来能否少写离线 DDL 和手工迁移脚本。

ClickHouse 团队以 pg_clickhouse 为例，拆解了外部数据包装器决定下推什么的过程，结论是下推首先是语义正确性问题，而不是把能推的都推下去。跨引擎的类型、函数和排序语义要逐条验证，工程上需要持续迭代。评估 pg_duckdb、pg_clickhouse 或者湖仓集成时，应该拿真实 SQL 和 explain 输出去测语义，而不是只看最好看的那组跑分。

Shopify 把库存预留系统从 Redis 迁到 MySQL，关键设计点是 SKIP LOCKED，并称在 2025 年黑色星期五的高峰达成了扩展目标。这是缓存与内存系统对上关系数据库的典型取舍案例：正确性、可观测性和运维一致性有时候比单纯的低延迟更值钱。高争用的库存、配额、令牌和预约系统可以重新评估数据库原语是否够用，但必须做真实峰值压测并观察锁等待。

Kubernetes v1.36 废弃 Service 的 .spec.externalIPs，理由是它在不可信的多租户集群里长期不安全，并与 CVE-2020-8554 的暴露面相关。官方建议已经不用这个字段的集群启用 DenyServiceExternalIPs 准入控制器，仍在用的迁移到 LoadBalancer、Gateway API 或 MetalLB。这是核心 API 的行为变化，会影响裸金属与边缘集群里的历史 YAML。