PostgreSQL 博览 RSS 订阅

PostgreSQL 已提交外部表统计导入的权限修复。此前，ANALYZE 沿用执行者身份从远端获取统计信息；没有远端数据权限的表所有者，可能借高权限用户的分析操作，从高频值等统计字段看到样本数据。补丁改为先切换到外部表所有者身份，使导入与抽样路径的权限一致，并回补至 19 分支。这是尚未正式发布的版本中的修复；它处理的是统计数据泄露风险，与此前导入原子性及旧版本兼容性修补不同。

PostgreSQL 外键快速检查路径新增函数执行权限校验。旧路径直接调用等值运算符函数，以及必要的隐式类型转换函数，却漏掉了常规查询路径已有的 EXECUTE 检查。新补丁在被引用表所有者身份下检查两类函数，并用普通表与分区表测试验证行为一致，已回补至 19 分支。此次新增检查针对函数权限，与近期关系访问权限和扩展权限钩子的修复不同；它使这条优化路径继续遵守原有的授权边界。

大表回填不能只盯着 HOT 更新比例。Mikhail Shytsko 用百万行表对比顺序分批与交错分批：在预留页空间并逐批清理的实验中，交错方式减少了索引更新；但若每批之间触发检查点，反复修改分散页面会产生更多完整页镜像，WAL 反而从约 1 GB 增至 3 GB。文章还测试了局部交错的折中方案。结论来自特定实验条件，运维时应同时观察检查点、页空间和 WAL，不能把更高的 HOT 比例直接等同于更低写入成本。

复制槽能保护尚未消费的 WAL，也可能让停滞的订阅端拖满主库磁盘。Christophe Pettus 解释了 max_slot_wal_keep_size：默认值 -1 不设上限，有限值则在检查点时约束复制槽需要保留的 WAL 范围，并非实时执行的磁盘配额。超过边界后，槽可能失去所需日志，逻辑复制需要重新初始化。文章建议结合写入峰值、磁盘余量以及槽的 WAL 状态安排监控；设置上限是在存储风险与复制可恢复性之间做取舍。

ClickHouse 26.9 为刷新型物化视图加入 APPEND INCREMENTAL 模式，让适用的追加写入数据只处理新提交记录，不必每次重扫全部来源。面向 Iceberg 的游标状态与快照共同提交，以保持增量边界一致。另一项更新让 DISTINCT 的去重集合在达到阈值后写入临时磁盘，缓解大基数查询的内存压力，但合并过程仍需要内存。两项变化分别面向持续数据加工与大规模查询；采用前仍需核对来源是否符合追加写入约束及临时存储容量。

containerd 披露镜像拉取过程中的拒绝服务漏洞 CVE-2026-53493。恶意 OCI 描述符图可通过过深或过宽的引用结构，让处理过程消耗大量 CPU 与内存；风险发生在拉取镜像时，无须先启动容器。修复为描述符遍历增加边界与去重处理，已进入 2.4.1、2.3.6、2.2.9、2.0.13 和 1.7.36。运行镜像构建、扫描或集群节点的团队应核对实际运行时版本；暂未更新时，应限制从不可信来源拉取镜像。

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 变更流伸缩器，并调整部分伸缩器的兼容行为。升级后应验证实际触发器与伸缩流程。

PostgreSQL 19 发布第四个测试版，进入正式发布前的收尾阶段。SQL/PGQ 图查询、在线启停数据校验和、时态数据分段修改，以及分区合并与拆分均已撤出本版；同时继续修复在线重整、外键检查和逻辑复制等功能的问题。项目组计划于 10 月初推出候选发布版，正式版可能在 10 月发布。测试环境应按大版本升级方式迁移并重新验证应用兼容性，依赖这些延期特性的项目也需要调整上线安排。

PostgreSQL 为此前披露的逻辑解码初始快照竞态合入修复：事务的提交记录已写入 WAL，但提交状态尚未更新时，快照可能把该事务误判为中止，并留下错误的行可见性标志，导致数据损坏。修复会等待事务退出活动进程数组，再完成可见性判断。问题在 PostgreSQL 19 在线重整的压力测试中暴露，实际影响更早版本；补丁已合入 14 至 19 的维护分支，交付仍需等待后续版本，不能将其视为 Beta 4 已包含的修复。

Christophe Pettus 解释预备事务与普通事务的运维差异：两阶段提交进入预备状态后，即使连接断开、后端终止或数据库重启，也会继续持锁并拖住垃圾回收，只能通过提交或回滚预备事务结束。默认关闭这项能力可以避免意外遗留事务；确需启用时，应监控预备事务的年龄，并预算对应的共享内存槽位。备库的容量设置必须不低于主库，提高上限时应先调整并重启备库，不能依赖普通会话超时机制清理这些事务。

Tiger Data 用 PostgreSQL 16 拆解插入的写入成本：数据行之外，每个索引还要维护自己的页面，并产生额外 WAL；检查点之后的首次页面修改又会增加全页镜像。厂商称，实验中三个索引让约 3.8 MB 的输入生成约 33 MB 日志。文章用日志位置和 WAL 统计测量放大倍数，同时提醒这些计数属于整个实例，需在安静窗口采样。优化应结合索引用途、批量导入和全页镜像压缩，不能把新增硬件当成降低写入放大的替代方案。

Delivery Hero 将广告事件处理迁至 Apache Flink，用异步查询补全维度信息，再通过有状态去重和跨天关联处理点击与转化。状态保存在 RocksDB，并把增量检查点写入对象存储；原始事件另行归档，支持故障恢复和重放。厂商称处理延迟由约 61 分钟降至 1.2 秒、成本下降 57%。这里的计费准确性依靠重复事件识别，不能直接等同于全链路恰好一次；报表汇总仍按批次写入，设计需要分别界定事件处理、计费和查询的新鲜度。

Cloudflare 披露并修复容器存储隔离漏洞：薄置备磁盘复用空间时跳过清零，新的容器可能读到同一宿主机上旧容器留下的数据。漏洞涉及已释放空间中的残留内容，并非直接读取其他正在运行容器的磁盘。修复不仅重新启用清零，还需更换运行中的磁盘和缓存镜像层，才能消除已有映射中的残留；清理已于 9 月 19 日完成。公司称现存遥测未发现研究者和内部测试之外的利用记录，事件凸显共享存储回收路径同样属于租户隔离边界。

Franck Pachot 用执行计划示例解析 PostgreSQL 19 测试版的 EXPLAIN IO 选项：传统 BUFFERS 统计缓存命中与读取块数，新指标则展示预取深度、实际 I/O 请求数量、请求大小、并发度及未及时完成的读取次数。示例将约 2.9 万次块读取合并为 1825 次请求，扫描只在其中 7 次遭遇尚未完成的 I/O。分析慢扫描时应结合这些指标判断预取是否隐藏延迟，不能把等待次数直接当作等待时长。

PgBouncer 1.26.0 修复三项拒绝服务漏洞：未认证客户端可触发进程崩溃或缓冲区增长死循环，恶意 PostgreSQL 服务端则可通过过大的 SCRAM 迭代次数拖住登录。新版本还默认跟踪搜索路径与事务只读状态，新增空闲连接池超时，并允许按用户和数据库设置查询排队超时。已弃用的在线重启选项 -R 被移除，维护连接池的团队需要同时核对认证风险、会话状态与升级时的重启方式。

安全研究者 Mehmet Ince 发布系列第二篇，称已向多家托管 PostgreSQL 厂商报告 76 项安全加固扩展漏洞。文章聚焦临时借用超级用户身份时的校验缺口：对象先按名称通过检查，切换身份后再次解析，却可能执行另一个对象；单纯屏蔽函数名也存在绕过路径。研究者称 Supabase 已修复其中四项问题。服务商审计需要覆盖对象身份、权限切换和底层危险能力，而不能只核对一份函数黑名单。

CloudNativePG 1.30.1 集中修复高可用控制流程：故障切换不再被已隔离实例拖住，待完成的切换持续推进，并在提升前重新检查仲裁安全；主节点启动 PostgreSQL 前必须先持有主租约，避免重启后过早接受写入。版本还修复扩展路径校验绕过，以及插件恢复将 WAL 写入错误卷导致空间耗尽的问题，同时补正备份与监控行为。同日发布的 1.29.3 是该分支最后维护版本，使用者需要安排迁往受支持分支。

Stefan Fercot 复现了备库在关闭归档时被提升的场景：即使让下游备库归档并成功生成新备份，也无法补回切换附近缺失的 WAL 和时间线历史文件，旧备份仍可能无法跨越该断点恢复。关闭归档模式检查并不会放行主库的归档关闭状态，修改工具绕过检查也不能证明恢复链完整。实验建议提前为候选主库启用归档并配置归档命令；若已进入错误配置，应通过计划重启或受控切换恢复，再验证跨时间线恢复能力。

FireTV 的观看进度原先把整个用户档案压成一个 DynamoDB 条目，档案增长后既逼近 400 KB 上限，也让每次小更新承担整块写入成本。团队改为按内容拆分小条目，再在排序键前加入哈希，将完整档案拆成多个范围并行读取，避开大结果集的串行分页。厂商称写成本下降 97%，平均读取约 8 毫秒；代价是读取字节增多，按内容提供方等条件查询还需额外索引。迁移通过双写、影子读取与全量比对逐步切换。

PostgreSQL 已合入一项备用库回放修复：只冻结元组或更新可见性映射的 WAL 记录，不再无条件申请清理锁。旧行为会等待其他进程释放缓冲区引用，即使记录并未移动或删除元组，也可能拖慢恢复并取消备用库上的查询。补丁把清理锁限定到真正执行页面修剪的记录，提交注明回补至 PostgreSQL 17；可见性映射的额外受影响路径从 19 起出现。这有助于减少分析查询与恢复进程之间不必要的冲突，已合入的修复仍需等待相应版本发布。

PostgreSQL 开发分支为 pg_upgrade 增加数据类型检查，阻止含有特定系统类型数组的用户表直接升级。数组值保存元素类型的 OID，而部分系统类型及 information_schema 域的标识可能跨大版本变化；升级工具不重写用户数据，旧值随后可能报类型查找失败，甚至被按错误类型解读。新检查提前列出问题列，要求删除或转换类型后重试。提交说明该场景较少见，暂未回补；这是升级前的数据完整性保护，并非对已升级数据的自动修复。

Dimitri Fontaine 用可重现的中心库与工作库示例，梳理 PostgreSQL 原生逻辑复制逐版消除的应用限制：中心库向各工作库分发必要的参考数据，工作库再把事件汇总回来。文章把行列过滤、复制标识、大事务流式传输及防止复制循环放到同一架构中，说明过滤列与复制标识必须配合，分散写入还要单独设计全局唯一键。示例同时划清原生功能边界：DDL 仍需另行迁移，冲突记录也不等于自动解决冲突。涉及 19 的序列复制明确属于测试版能力。

一次性执行的 SQL 即使成功，也未必长期留在 pg_stat_statements 中。Mikhail Shytsko 的实验展示了大量不同查询形状挤出低频写操作的过程，并解释统计视图按角色、数据库与查询标识等聚合，无法仅凭应用名区分共用账号的调用方。默认只追踪顶层语句，函数内语句与失败操作还存在其他可见性边界。排障时应观察淘汰计数、为调用方分配角色，并结合带身份信息的日志；扩大统计容量可以缓解淘汰，却不能把聚合统计变成持久审计记录。

AWS 分析了大型 Kafka 消费组反复再均衡的一条隐蔽路径：协调器写入内部位点主题的组元数据，可能随成员、订阅与名称长度增长，超过记录大小限制。提高业务消息上限并不能直接解决这个内部主题的问题，还必须协调主题记录上限与副本拉取上限，避免复制落后。文章同时讨论拆分消费组、限制自动扩容规模和缩短命名带来的取舍。调大限额会增加代理处理再均衡时的堆内存压力，因此需要连同垃圾回收、复制健康与消费进度一起验证。

同一 URL 按语言或格式返回不同内容时，缓存既要避免串用响应，也要防止请求头的细微差异制造大量冷缓存。Cloudflare 将 Vary 支持加入所有套餐的缓存规则，允许按请求头选择归一化、原值匹配或绕过缓存，并把归一化后的部分协商头传给源站，保持缓存选择与源站行为一致。源站仍须稳定声明正确的 Vary 字段；个性化或高基数请求头适合绕过缓存，Vary: * 始终绕过。修改配置不会自动清理旧缓存，发布时仍需验证各变体并按需清除内容。

此前报道的多列范围分区裁剪问题已有实质进展：当分区上界含 MAXVALUE，部分查询会错误排除默认分区，静默漏掉本应返回的行。修复重新安排了边界判断，并加入回归用例；相关提交已进入主干和 PostgreSQL 19 稳定分支。它处理的是查询结果正确性，而非单纯的执行效率。使用多列范围分区与默认分区的团队可用原始用例检查自己的查询，并关注后续维护版本是否包含该修复。

PostgreSQL 的共享内存接口允许调用方在不知道大小时附着到已有对象，但目标不存在时，旧路径会把特殊大小值当成分配请求，触发整数溢出并可能损坏内存。新提交明确拒绝这种创建请求，同时给底层分配器补上溢出检查、文档与测试，已合入主干和 PostgreSQL 19 稳定分支。影响集中在调用该接口的代码与扩展，维护者需要检查未知大小附着的失败处理；这一变更尚不能等同于已发布的维护版本。

事务结束会归还数据库连接，却不意味着所有会话状态都已清空。一组可复现测试梳理了 PgBouncer 事务池中的租户变量、角色、搜索路径、临时表与会话锁：普通 SET 留下的状态可能被下一个借用者看到。文章将租户隔离落实到显式事务和 SET LOCAL，并要求行级安全策略在上下文缺失时拒绝访问。还需分别处理临时表与锁的生命周期，不能把连接池视为租户隔离边界；协议级预备语句的跟踪也不能替代这些约束。

SQL Server 存储过程一次调用可返回多个独立结果集，迁到 PostgreSQL 时不能只改 SQL 语法。AWS 对比了游标、会话临时表与 JSON 聚合三种方案：临时表便于保留关系结构和流式读取，但创建与读取必须在同一连接、同一事务中完成；JSON 可合成一次响应，却需要控制结果规模和内存。文章同时给出数据库与 Npgsql 客户端改造及等价性验证步骤，帮助迁移团队把结果形状、排序和连接池行为一起纳入验收。

Redis 发布多条维护分支的安全更新，其中 8.10.2 修复了事务排队后撤销 ACL 权限仍可访问相关键的问题，并处理时间序列、向量检索和深层 JSON 输入引发的崩溃。集群总线还新增未认证启动告警，以及要求总线启用 TLS 认证的可选保护配置；该选项默认关闭。对使用细粒度权限和集群部署的团队，这次更新既涉及升级，也涉及核对总线网络暴露与认证设置，不能把新增告警误当成认证已自动启用。

Cloudflare 将 Python Workers 推向正式可用，补齐常见 Web 框架、服务绑定与网络访问能力。TCP 桥接让常用数据库客户端可配合 Hyperdrive 访问 PostgreSQL 和 MySQL，WSGI 与 ASGI 支持则帮助已有应用接入。依赖原生扩展的包仍需适配 WebAssembly 构建，迁移时要核对依赖和运行约束；变化的重点是把 Python 应用与数据库连接纳入边缘运行环境。

PostgreSQL 简体中文消息长期存在未译条目、术语不一和格式占位符错误。冯若航公布了针对 PostgreSQL 14–19 的校准工作，项目统计覆盖 162 个目录文件、67,487 条消息。流程先固定术语与翻译规范，再逐项对照英文审校，并跨组件、跨版本检查一致性，使用 msgfmt 校验格式。本轮还修正了遗漏系统错误原因、引用多余格式参数等问题。上游开发期仍会新增或调整消息，后续通过跟踪仓库持续补齐。

并行查询的参数上限不等于实际启动的工作进程数。Christophe Pettus 通过执行计划和并发实验说明，单个 Gather 的规划上限只是请求许可，多个 Gather 还可分别申请进程。集群虽统一统计已运行数量，max_parallel_workers 却可由普通会话修改；真正的硬上限来自 max_worker_processes。运维应同时核对计划与实际启动数，为逻辑复制和扩展预留槽位，防止报表查询耗尽共享进程池。

Databricks 将此前处于测试阶段的 Lakebase Search 推进到正式可用。两个 PostgreSQL 扩展分别提供兼容 pgvector 类型与查询语法的近似向量索引，以及面向标准 tsvector 的 BM25 排序和前 K 项下推，应用可在同一数据库组合语义与关键词检索。索引保存在存储层，计算实例缩到零后再次启动无需重新预热索引。使用前需在项目设置启用功能并安装扩展，具体账号仍按分阶段发布节奏获得更新。

DBAglobe 实测了用 Debezium、LogMiner 和 MSK 将 Oracle 复制到 Aurora PostgreSQL 的链路，覆盖初始快照与后续增删改。类型映射是关键：NUMBER(19,0) 在所用配置下转为 Decimal，目标应选 numeric，不能直接当作 bigint。托管接收端还出现 Jackson 类路径冲突，实验改用自管接收端完成复制。所选日志解析策略不跟踪在线 DDL，迁移前须单独评估模式变化。

美联航将湖仓数据保存在 S3，用 Unity Catalog 管理，同时使用 Redshift 分析。其工程案例通过 Glue 目录联邦和 Iceberg REST 接口连接两者，再创建资源链接供外部模式访问。Lake Formation 在查询时提供受限的临时凭据，省去另一条数据同步管线。配置时须分别授权资源链接与目标表；Delta 表还要启用 UniForm，才能提供兼容元数据，不能仅连通目录就假定所有表均可查询。

把 Git 文件访问直接映射为对象存储请求，会让细碎读写累积成网络延迟。Tigris 的 objgit 实验重做了 packfile：用数据文件与独立索引记录对象偏移及压缩前后的长度，使服务端可通过 HTTP Range 精确读取对象，并在后台预取整个包。作者比较了三类仓库的请求次数和推送、克隆耗时，显示减少往返比简单替换存储接口更关键。这一进展仍是存储布局实验，鉴权与包合并机制尚未实现。