PostgreSQL 博览 2026-09-25 RSS 订阅

PostgreSQL 已提交并发 REPACK 的正确性修复：表通过免重写方式增加列后，部分旧元组不含新属性，解码时误用临时表的描述信息，会把默认值还原成 NULL，甚至破坏非空约束。若该列属于副本标识，还可能找不到待更新行或触发比较函数崩溃。补丁改用源表描述信息，并增加隔离测试，已回补至 19 分支。这个修复针对并发变更的旧元组处理，与此前的 TOAST 解码及索引检查问题不同。

pgwrh 发布首个 1.0 Alpha，面向 PostgreSQL 18，将分区叶子表按加权哈希分布到逻辑副本，并用自带的 FDW 路由查询。放置规则支持可用区与副本数量约束，拓扑切换可检查就绪状态并回滚；独立等待扩展能先等到指定 LSN，再取得读取快照。写入仍集中在控制节点，逻辑复制仍是异步的，放置冗余不替代控制节点高可用。该版本供测试，暂不提供协调式模式变更或自动选主，部署前需明确读扩展与故障恢复的边界。

工业传感器的字段字节数不能直接充当数据库容量预算。Tiger Data 用 PostgreSQL 16 的样表说明，原始字段合计 20 字节，算上堆存储与写入时建立的索引，实测平均每行约 95.6 字节。厂商称，按每秒一万条、保留两年外推，未压缩存储需求约为 60 TB。差距来自元组头、对齐、页面与索引，而非业务字段增长。文章建议用真实模式、计划中的索引和批量载入样本测量每行成本，再估算留存与后续压缩空间。

PostgreSQL 的存储等待不一定能靠调整数据库参数解决。Stormatics 总结 Azure 虚拟机上的四类磁盘陷阱：磁盘跨过主机缓存容量阈值、虚拟机先于磁盘触及吞吐上限、容量档位限制 IOPS，以及数据与 WAL 共用磁盘。对支持主机缓存的磁盘，扩容到 4 TiB 及以上将失去原有缓存收益。排查应同时对照等待事件、系统 I/O 与云端限额，并把数据文件和 WAL 的读写特征分开考虑；提高磁盘 IOPS，无法解除虚拟机瓶颈。

AWS 给出一条由托管组件组成的 PostgreSQL 变更采集链路：Fargate 任务通过 wal2json 读取逻辑复制流，将事件交给 EventBridge，再经 SQS 与 Lambda 写入 S3。方案省去自建消息集群，适合将行级变化留作分析输入，同时把采集、缓冲与落盘拆开扩缩。运维重点仍包括复制槽滞后和 WAL 保留上限、队列死信与重试，以及下游幂等处理；队列采用至少一次投递，不能把组件托管等同于端到端恰好一次。

KEDA 2.21 默认要求服务账号令牌显式绑定受众，阻止认证配置把可访问 Kubernetes API 的令牌转发给租户控制的端点。这项安全修复会影响 Vault 的 Kubernetes 认证和各类绑定服务账号令牌认证：升级前需配置接收方、令牌受众及账号映射，不能只确认控制器启动成功。新版还加入 ClickHouse、Spanner 与 Cosmos DB 变更流伸缩器，并调整部分伸缩器的兼容行为。升级后应验证实际触发器与伸缩流程。