PostgreSQL 博览 RSS 订阅

EDB 发布 Barman 3.18.0，重点是把云备份并进统一体验。实验性的块级增量云备份只上传发生变化的数据块，底层用 pg_basebackup 流式备份，经本地暂存区直接写入 S3、Azure Blob 或 GCS，不在 Barman 主机上保留完整副本。云操作也在逐步并入主 CLI，取代独立的 barman-cloud 脚本，另有云 WAL 归档的内存压缩与 LZ4 压缩。需要注意增量备份的恢复尚未提供。

HexaCluster 发布 plpgsql_wrap v1.0，作用类似 Oracle 的 WRAP：用这门语言创建的存储过程先经校验，再以 AES-256-GCM 加密写进 pg_proc.prosrc，没有密钥就看不到明文，pg_dump 导出的同样是密文且可直接还原，另有 unwrap_procedure() 凭密钥取回源码。首个公开版本兼容 PostgreSQL 12 及以上，面向把存储过程交付给第三方时保护业务逻辑的场景。

DuckDB 官方特意说明 1.5.3 不是普通补丁版本：Quack 成为核心扩展，DuckLake、Iceberg、AWS 与 HTTPS 等扩展能力同时发生变化。版本号是 patch，行为面却覆盖数据湖表格式、远程协议和云对象存储路径，升级风险高于一般修补版。使用 DuckDB 扩展、DuckLake、Iceberg 或远程访问的团队应先读变更说明再升级，生产上的 notebook 与 ETL 环境不宜只看版本号就自动放行。

Turso 用形式化建模工具 Quint 给 SQLite 的 C API 建模，生成操作序列与真实实现做差分验证，找出十多个 bug。这不是靠模型猜错误，而是规约与模型检验驱动的系统性测试：把事务状态机和边界 API 写成规约，再让工具去构造违反预期的路径。SQLite 被极其广泛地嵌入在各类软件中，这条路径说明数据库可靠性工具链正从论文走向工程实践，维护嵌入式数据库或复杂状态机的团队可以照着做。

Railway 发布事故报告：Google Cloud 错误暂停了它的账号，托管在 GCP 上的基础设施随之全平台中断。事故说明多区域部署并不等于账号级的风险隔离，当云厂商的合规、支付或滥用检测对账号执行全局动作时，下游服务可能同时失去计算、网络、镜像和控制面权限，这是绕过传统多区架构的硬中断。关键平台应把云账号被封列进灾难场景，预先准备升级路径、备用组织、出云备份和状态页沟通模板。

pgBackRest 官方宣布项目将继续维护：过去几周形成了由 AWS、Supabase、pgEdge 等组成的赞助联盟，不再依赖单一赞助方。备份工具的维护是否可持续，直接影响恢复演练、合规审计和灾备设计，此前资金与维护者时间的不确定性让依赖它的自建集群和商业平台都在承压。使用 pgBackRest 的团队短期内不必仓促迁移，但仍应保留替代恢复方案，并关注后续路线图、发布节奏与漏洞响应。

Percona 宣布硬分叉 Crunchy 的 PostgreSQL operator，做一个镜像可自由再分发、治理开放、功能不设付费墙的替代品，并保持与现有 Crunchy 部署兼容，可以通过备用集群提升或备份恢复迁移过去。背景是开源分发在收紧：MinIO 4 月归档了开源代码库，Bitnami 把生产镜像挪进付费订阅，Crunchy 的 operator 镜像现在需要认证并限制再分发，离线部署和 GitOps 流程因此受影响。

PostgreSQL 19 可以在线修改 wal_level，不再需要重启实例。此前要启用逻辑复制必须在计划停机窗口里切换 WAL 级别，不少组织为了免去协调重启的麻烦，干脆长期以更高的 WAL 开销运行。改动之后转向逻辑解码不再牵扯重启，WAL 级别可以按实际的复制需要调整。对准备启用逻辑复制、做迁移或 CDC 的团队，这项变化把一次跨团队的停机协调降级成一次参数变更。

EnterpriseDB 的案例文章记录一家大型跨国银行把 PostgreSQL 运维从虚拟机迁到 Kubernetes 原生架构的过程。迁移不只是换个承载方式，还要按编排能力重新设计日常运维流程，同时守住银行环境要求的可靠性与安全标准。文章从操作流程、扩缩策略和容器化环境下的数据库性能几个方面给出经验，对正在评估同类转型的 DBA 团队有参考价值，也和当天的 operator 选型讨论互为背景。

AWS 披露 CVE-2026-8838：Amazon Redshift 的 Python 驱动在 2.1.13 及更早版本存在代码注入，恶意的服务端或中间人可以在客户端执行代码。NVD 指出问题出在 vector_in() 对服务端数据使用了 Python eval()，CVSS 3.1 评分 9.8。驱动常被 ETL、BI、notebook 和 CI 任务反复复用，应立刻盘点依赖版本、升级到 2.1.14 并轮换相关凭据。

SafeDep 报告 Mini Shai-Hulud 供应链攻击再度发作，314 个 npm 包被投毒，Cybernews 给出的统计是 323 个包、639 个版本。这类自传播式污染攻击的是开发者生态的信任链，上周的 TanStack 事件已经显示，AI SDK 与前端工具链的包生态是窃取凭据、在 CI 里横向移动的高价值目标。应锁定依赖版本，检查近期安装日志，轮换 GitHub、npm 与云上的密钥。

Christophe Pettus 挑出 PostgreSQL 19 里最能被感觉到的四项变化：MultiXact 成员计数器扩到 64 位，高并发共享行锁不再耗尽四十亿成员空间、逼出停机 vacuum；autovacuum 可以并行处理索引，代价是每个工作进程各占一份 maintenance_work_mem；UPDATE 与 DELETE 支持 FOR PORTION OF，按子区间改写时段行；jit 默认关闭，靠代码生成的 OLAP 需要显式打开。

MultiXact ID 是 32 位计数器，一行被多个事务同时加锁、xmax 放不下时由它指向锁列表，它与 XID 各自独立回绕。SELECT FOR SHARE 会生成 MultiXact，外键检查隐含的 FOR KEY SHARE 也会，后者对开发者不可见。年龄逼近默认四亿的冻结上限时，数据库开始拒绝部分写入。作者建议用 mxid_age() 盯住库级与表级年龄，重点看外键父表。

Sergey Kuznetsov 发布 pg_sorted_heap 0.14.0，扩展提供物理有序的堆存储、zone map 裁剪和与规划器集成的向量检索。新版本把 PostgreSQL 16 加入已验证矩阵，与 17、18 并列，并把跨大版本的升级路径纳入发布门禁；sorted_hnsw 通过索引访问方法对规划器可见，覆盖父表在叶子分区 HNSW 索引之上的 Merge Append 形态。扩展已发布到 PGXN。

Gabriele Bartolini 对比两个 Kubernetes 上的 PostgreSQL operator，维度包括架构、镜像、备份、大版本升级、可观测性与社区健康度。作者是 CloudNativePG 的联合创始人，立场并不中立，但这份清单值得照着问：在 Kubernetes 上跑 PostgreSQL 已从能不能跑，变成谁为备份恢复、升级、故障转移和漏洞响应负责。评估时应看升级语义、恢复演练和多可用区故障模型。

AIDB 是 EDB 推出的 PostgreSQL 扩展，把 AI 数据准备流程放在数据库内部：新数据写入后自动完成分块、生成嵌入和维护向量索引，不再需要外部管道逐步处理。官方博客用一份调查报告 PDF 演示，把含多个实体与关系的复杂文档转成可查询的知识库，全程无需人工干预。对已经把非结构化文档放在 PostgreSQL 里的团队，这类扩展把嵌入生成与索引更新的调度交给数据库自身，少了一处同步失败和数据陈旧的来源。

Fabricked 项目展示了如何通过错误配置 Infinity Fabric 突破 AMD SEV-SNP 的威胁模型，论文投向 USENIX Security 2026。机密计算的边界不只在客户机内部，还包括固件、fabric、平台初始化和 hypervisor 可触达的配置，一处配置错误就可能影响客户机的完整性与机密性。依赖机密虚拟机的云数据库与推理服务应跟进 AMD、OEM 和云厂商的响应，把证明链与平台配置纳入评估。

Grafana Labs 确认系统被入侵、源代码被窃取，攻击者以公开代码库相要挟索要赎金，公司公开拒绝支付。做监控与可观测性的厂商同样会成为目标，被窃的专有代码是否最终会被公开尚不确定。拒付符合业界抵制勒索的方向，但也意味着要为代码外泄做准备：核对是否有凭据、密钥随代码一起泄露，检查构建与发布链路的可信度，并跟进厂商后续的事件说明与补救措施。

CNCF 的一篇文章指出临时容器的退出码只在很短时间内可见，它没有普通容器的 lastState 与 restartCount 语义，这是 API 设计的结果而不是简单缺陷。事故现场用 debug 容器观察到的状态往往是唯一的一手证据，Pod 后续一更新就无从追溯，影响复盘与合规审计。平台团队应把调试会话的命令、输出、目标容器、时间戳和退出码记进独立的审计或事故笔记，不要指望 Kubernetes API 长期保留这些上下文。

AWS 为 Amazon RDS for PostgreSQL 的 Extended Support 发布 11.22、12.22 与 13.23 三个小版本，修复旧大版本里已知的安全漏洞和缺陷。这三个大版本已离开社区标准支持，Extended Support 最长再提供三年关键修复，升级可走维护窗口、自动小版本升级或蓝绿部署。仍留在这三个版本上的实例应把补丁列进安全例外清单，同时安排迁出。

Christophe Pettus 的 GUC 系列讲后台写入器：bgwriter_delay 决定它多久醒来一次写出脏页，避免查询在需要干净缓冲区时卡在 I/O 上；bgwriter_flush_after 在写出一定字节后提示内核回刷，防止页缓存堆积脏数据。他建议两个都保持默认，先调 bgwriter_lru_maxpages 与 bgwriter_lru_multiplier，因为延迟控制的是节奏而非吞吐。

一次分区策略调整让 Cloudflare 的 PB 级计费管道卡住，时间并没有花在扫描上，而是耗在查询尚未执行的计划阶段：parts 数量膨胀后 planner 的锁竞争成了瓶颈。团队缩小锁范围、改进 planner 路径，并利用分区键有序性对 parts 做二分裁剪，3 月上线的这项优化把查询时延降低约一半，修改已提交上游。用 ClickHouse 做计费或多租户指标的团队值得监控 parts 数量与 planner 耗时。

HA 控制面滚动升级时，旧的 API server 遇到不认识的资源会直接返回 404，CRD、聚合 API 和新内置资源的访问因此出现异常。Kubernetes v1.36 把 Mixed Version Proxy 提到 Beta 并默认启用：旧 API server 把这类请求代理给版本更新的对等节点应答。升级到 v1.36 的平台团队应确认特性开关与多副本 API server 配置，并把版本偏斜补进故障演练。

GitHub Advisory Database 记录了 @tanstack 系列 npm 包被投毒，恶意版本会收集云凭据、GitHub token 和 SSH 私钥。受影响项目本来使用 Trusted Publishing，OIDC 短期凭据减少了长期 token 暴露，攻击者转而瞄准 CI 的信任边界、缓存污染和运行时 token 抽取。用可信发布的项目仍需审计 pull_request_target 与缓存键，收紧发布流程权限。

CloudNativePG 发布 1.29.1 与 1.28.3，修复指标导出器中 CVSS 9.4 的 CVE-2026-44477。导出器原先以超级用户身份连接再用 SET ROLE 降权，低权限角色可借此提权并在主节点容器里执行任意命令。新版本改用权限受限的 cnpg_metrics_exporter 角色，同时修正三个高可用故障转移缺陷，其中一个涉及数据安全。项目方要求所有用户立即升级。

数千个值的 IN 子句在 PostgreSQL 里是隐蔽瓶颈：规划器逐个解析常量、展开成庞大表达式树，CPU 花在规划而不是执行。TigerData 实测把写法换成 ANY(ARRAY[...])，上千个 ID 作为单个数组参数传入，规划时间从 40 多毫秒降到 2 毫秒以内，并让规划器选择 Bitmap Index Scan。ORM 是超大 IN 子句最常见的来源，用 EXPLAIN ANALYZE 看规划是否超过总耗时一半即可判断。

pgcrypto 自 2005 年随 PostgreSQL 分发，两个漏洞在其中潜伏了约二十年。去年 12 月 ZeroDay.Cloud 的 AI 辅助模糊测试挖出这两个远程执行漏洞：一个是 PGP 会话密钥解析里缺少边界检查的堆溢出，另一个是编码校验缺陷，都能在数据库进程内执行任意代码。修复随 2 月的小版本发布，18.0、17.7 及更早的实例仍可被利用；这些函数默认授予 PUBLIC，作者建议回收公共执行权限。

PostgreSQL 解析 ORDER BY 有两条路径：裸列名按 SQL-92 先查 SELECT 列表再回到表，包成表达式后按 SQL-99 只查 FROM 作用域。别名与输入列同名而取值不同时，ORDER BY a 与 ORDER BY -a 返回同样的行却是不同的顺序，加一个正号或 COLLATE 就足以切换路径；GROUP BY 的查找顺序又相反。要在表达式里用别名，只能套一层子查询把它移进 FROM。

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。

Robins Tharakan 在 Planet PostgreSQL 上预告 2026 年 5 月的 PostgreSQL 安全更新，涉及 11 个 CVE，覆盖 14 到 18 全部受支持版本。他列出的方向包括 multirange 权限、内存溢出、pg_basebackup 的路径穿越、逻辑复制相关的 SQL 注入。正式公告尚未发布，可以先盘点实例、扩展和备份复制链路，等官方 release notes 再定升级动作。

CVE-2026-2005 是 pgcrypto OpenPGP 代码路径上的堆缓冲区溢出，可以以数据库进程的身份执行任意代码。Christophe Pettus 指出这段代码是 2002 年移植的 C 实现，长期缺少模糊测试，又归在 contrib 下，审视强度低于内核，于是漏洞随每个版本一路发布了二十年。补丁在 18.3、17.9、16.13、15.17 和 14.22 里，只用 digest() 与 crypt() 的不受影响。

Snowflake 收购 Crunchy Data 后，Crunchy PGO v6 上的集群要考虑退路。Gabriele Bartolini 给了两条路：离线那条用 CloudNativePG 内置的 pg_dump 导入，停机随数据量增长；在线那条用逻辑复制持续同步，由 Publication 与 Subscription 两个 CRD 描述，切换时排空队列，停机以秒计。序列仍要手工同步，原生支持要等 PostgreSQL 19。

Jimmy Angelakos 发布 pg_statviz 1.0，给这套 PostgreSQL 统计可视化工具加了可选的 --ai 分析，支持 Claude、Gemini 和本地 Ollama 三种后端，并把用户派生的数据包裹起来以防提示注入。仪表盘、规则和大模型解释拼在一起能降低读统计信息的门槛，但错误建议和数据外传的风险也同时上升。把生产统计发给外部 API 之前，要确认配置项、角色名、复制槽和查询文本里有没有业务敏感信息。

DuckDB 介绍了 Quack 协议，让 DuckDB 实例之间以客户端服务器的方式访问远程数据。文章把它明确放在原有的进程内架构之外，是新增能力而不是替代。DuckDB 已经是本地分析、ETL 和应用内 SQL 的常见选择，官方远程协议会把它推向服务化分析、边缘数据和轻量 BI，也可能省掉为共享数据而绕道 PostgreSQL 或 Flight SQL 的那一层。上生产前仍要看权限、并发和稳定性。

Kubernetes v1.36 引入 scheduling.k8s.io/v1alpha2 下的 Workload 与 PodGroup 对象，以及新的 PodGroup 调度周期，配合拓扑感知调度、成组调度和 DRA 的 ResourceClaim。GPU 训练和多 Pod 分布式任务靠逐个 Pod 调度效率很低，这批 API 进入主线，说明 AI 负载正在反过来塑造云原生控制面。平台团队可以跟踪它的成熟度，避免过早绑死私有调度器。

dnsmasq 维护者在邮件列表上说明，CERT 即将发布六个严重安全漏洞的 CVE。dnsmasq 是那种看不见却到处都在的 DNS 与 DHCP 组件，家用路由器、小型办公网络、Linux 桌面、开发用虚拟网络和嵌入式设备里都有它，多个严重漏洞同时释放，意味着补丁传播和设备厂商的响应会很不均匀。可以先盘点基础镜像、路由器固件和虚拟机开发网络里的用法，等发行版公告后优先升级，升不动的边缘设备做网络隔离。

XBOW 公布了编号 CVE-2026-45185 的 Dead.Letter 漏洞，称在 Exim 中发现未认证的远程代码执行。Exim 是部署量很大的邮件传输代理，邮件服务器通常直接暴露在公网上，历史上又长期是自动化扫描的目标。运维 Exim 的团队应尽快关注上游与发行版的补丁和临时缓解措施：即便邮件不在核心业务链路上，这类主机也常常成为进入内网的第一跳。

Cloudflare 复盘了一个看上去与协议无关的故障：Linux 内核的一项 idle 优化会触发 QUIC 行为异常，形成他们所说的死亡螺旋，文章记录了从现象到定位再到修复的完整路径。基础设施团队遇到 QUIC 或 UDP 问题时习惯先怀疑网络或应用实现，这次复盘说明内核优化和 CPU 空闲策略同样可能被放大成协议层故障。跑高吞吐 QUIC、RPC、数据库代理或边缘网关的团队值得把 CPU 电源状态和尾延迟一起纳入观测。