PostgreSQL 博览 RSS 订阅

PostgreSQL 开发主线已提交外键快速路径批处理层的回退。此前 PostgreSQL 19 分支已移除这层优化，主线曾保留它继续修正；新的触发器语义问题促使开发者放弃当前实现。当行后触发器修改被引用表时，延后成批校验可能偏离逐行检查的行为。此次删除缓存外键行与集中探测的机制，但保留绕过 SPI、直接访问主键索引的逐行快速路径。变化发生在开发树，相关测试应按新的执行边界重新核对。

大规模物理备份会顺序读遍数据库，挤出操作系统中仍有价值的热数据。ClickHouse 团队介绍其托管 Postgres 对 WAL-G 的调优：使用直接 I/O 绕过页缓存，再把单次读取扩大到覆盖 RAID0 条带，弥补失去内核预读后的吞吐下降。厂商测试中，直接 I/O 保住了预热表的缓存，而默认缓冲读取几乎将其清空。文章同时比较读取并发、查询尾延迟和 CPU 开销，说明备份速度与在线负载保护需要一起衡量。

PostgreSQL 的并行扫描最小尺寸参数既控制是否考虑并行，也影响分配多少工作进程。Christophe Pettus 通过计划与实验说明，规划器从该阈值出发，按扫描规模逐级增加进程；把阈值设为零，可能让很小的查询也申请过多进程。索引扫描、仅索引扫描与位图扫描采用的尺寸依据各不相同，表级设置又能覆盖默认估算。参数还影响并行建索引与清理的适用边界，因此调优时应同时检查计划代价、数据规模和实际并发。

多租户系统按租户均匀分配，并不意味着每个分片的负载均衡：少数大租户可能占据大部分数据和请求。PlanetScale 以 Neki 为背景分析处理路径，从单独扩容热分片，到隔离大租户，再到按具体表的访问模式更换分片键。文章用消息表从工作区改按频道分片说明，拆分必须保留常用查询的局部性；迁移则需要先复制数据、持续追赶变更，最后切换路由。这些取舍把容量规划与数据模型联系起来，不能仅靠增加分片数量解决。

长时间运行的数据迁移需要在同步进程故障后继续追赶。Percona ClusterSync for MongoDB 1.0.0 引入主备模式，通过目标库中的租约选出活跃实例，并用递增任期阻止失去租约的旧进程继续写入检查点。备用实例可从已保存的位置接管持续复制，租约使用服务端时间判断过期，降低节点时钟差异的影响。当前初始克隆仍不能断点恢复，失败后须重新开始；旧版状态也不能直接沿用，升级与演练应分别验证这两个阶段。

Caddy 2.11.7 修复了 2.11.6 超时调整带来的多种代理回归。此前新增的请求体读取期限可能截断持续发送的请求；HTTP/2 写入空闲计时也可能误伤暂时没有数据的长连接。另一个问题是期限回调晚于处理器结束，导致反向代理发生空指针崩溃。新版本调整这些期限的作用范围，并继续完善流式响应处理。近期升级过的服务应重点回归长时间上传、事件流和安静一段时间后恢复发送的连接，确认安全超时与正常业务兼容。

多个租户共用 PostgreSQL 任务队列时，大租户的积压可能让小租户长时间等待。Chris van Eijk 用四个工作进程比较先来先服务与按租户轮转：在其测试中，小租户完成时间中位数从约 4.5 秒降至 0.1 秒。文章进一步揭示，单有公平调度仍不够；大量空租户与积压任务会让按全局编号排序的查询选错索引。让排序匹配租户局部索引，并只扫描活跃租户，才能兼顾公平性与取任务成本。测试结果对应文中负载，仍需按实际租户分布验证。

分片代理需要汇总多个 PostgreSQL 实例的结果，但每层完整解码再编码都会增加 CPU 与内存开销。PlanetScale 披露 Neki 的结果处理设计：简单查询直接转发原始行字节，限制行数只解析行边界，跨分片排序则仅解码排序键并缓存结果。原始数据行被装入内部通信消息，以保留文本、二进制格式及扩展类型的表示。这篇工程分析说明了分片路由层怎样按运算需要逐步解析数据，也强调缓存生命周期与内存核算仍须明确管理。

Supabase 展示 PostgreSQL 扩展路线。Multigres 托管服务进入私有 Alpha，跨同一区域的三个可用区部署，结合同步复制、共识机制与连接池提供高可用。OrioleDB 则进入公开 Beta，新项目可选择这一使用撤销日志的引擎，并在同库混用原生堆表与 OrioleDB 表；其目标包括减少更新造成的膨胀与冻结维护负担。两者仍处于测试阶段，分别改变集群组织与表存储方式，评估时需要单独核对兼容性、故障恢复和运维行为。

OpenStack 发布代号 Hibiscus 的 2026.2 版本，扩充自建云的计算隔离与数据服务。Nova 增加 AMD SEV-SNP 和 Intel TDX 支持，Designate 改进 DNS 隔离，Manila 纳入新存储后端，Glance 支持并行导入镜像。这一版属于非 SLURP 版本；使用 2026.1 的部署可按策略跳过它，等待下一次 SLURP 发布。新能力为私有云提供选择，落地需逐项核对硬件、驱动与配置。

Cloudflare 将日志、请求追踪与分析查询整合到同一观测平台。新公布的 Traces 公开测试覆盖边缘至源站链路，支持 OpenTelemetry 与 W3C 追踪上下文；SQL API 和自定义告警也进入测试阶段，可用于查询遥测数据并接入既有工作流。Logpush 自助配置与日志转换能力则已正式提供。各能力的发布状态并不相同，跨数据集联接仍待后续开放；团队可以先验证链路关联与日志处理效果，再评估计划于 12 月启用的新计费方式。

Prometheus 发布 3.13.4，更新 gRPC 依赖以修复 HTTP/2 数据帧碎片导致的内存耗尽问题，并升级界面中存在漏洞的依赖。本次还修正联邦采集中的浮点原生直方图损坏，以及样本数和各桶计数均为零时的抓取失败。Agent 遇到未知 WAL 记录类型时改为忽略，以支持从较新版本回退。升级评估应覆盖监控服务本身的安全性，也要核查直方图数据与回退路径，尤其是使用联邦抓取、原生直方图或 Agent 模式的部署。

Pgpool-II 为五个受支持分支发布安全更新，修复七项漏洞，涉及 watchdog 消息处理中的内存破坏、认证绕过和信息泄露，以及客户端证书身份校验。修复版本为 4.7.3、4.6.8、4.5.13、4.4.18 与 4.3.21。使用集群故障切换或证书认证的部署应核对受影响条件并升级；已停止维护的 3.5–4.2 分支不再提供补丁，需要迁移到受支持版本。

ParadeDB 在回应全文检索基准测试时公布两项新的 BM25 优化：把文档长度信息按倒排列表排列，减少随机访存；对多词稠密查询采用 MAXSCORE，减少无效评分工作。相关改动已进入 0.26.0-rc.2，正式版尚待发布，完整收益需要重建索引。文章还说明查询配置、评分参数与排名一致性会影响对比结论。这次进展是检索执行与存储布局的改进，实际效果仍需用自己的数据和查询复测。

分布式数据库中的外键既要维护引用完整性，也要处理并发修改。AWS 说明 Aurora DSQL 如何在快照读取与提交阶段的乐观并发控制之间完成校验，不依赖传统行锁等待。文章给出异步验证已有数据、可延迟约束和级联操作的用法，并指出应用必须重试序列化冲突。级联修改仍计入单事务 3,000 行限制，迁移 PostgreSQL 应用时需要重新审视大批量删除与重试边界。

DynamoDB 向 S3 导出新增条件筛选与字段投影，可从时间点恢复备份中提取所需租户、记录和属性，覆盖全量与增量导出，不消耗业务表的读取容量。分区键条件能缩小备份读取范围，普通过滤表达式则只减少输出，不能等同于减少扫描工作。文章进一步演示选择性恢复与跨表迁移，强调应使用条件写入避免覆盖目标表的新修改。团队可据此拆分共享数据和恢复范围，无需先导出整张表再处理。

Cloudflare 将数据摄取、目录管理与 SQL 查询整合为正式可用的 Basin，底层采用 R2 对象存储与 Apache Iceberg。数据可经 HTTP、Workers 或 Logpush 进入流水线，转换后落入开放表格式；目录服务负责文件合并、快照过期与元数据维护，SQL 引擎支持连接、窗口函数和公共表表达式。既有组件配置继续有效，其他兼容 Iceberg 的计算引擎也能访问数据，团队可把采集、维护与分析连成统一流程。

Caddy 2.11.6 发布安全修复与连接处理改进，同时收紧若干默认值。请求头大小上限从 1 MB 降至 16 KiB，新增读写空闲超时以限制停滞连接；含点号的请求头默认丢弃，更具体的站点块也不再隐式继承通配站点的客户端证书认证配置。反向代理与认证转发的连接处理问题一并修复。维护者应在升级前检查较大的请求头、慢速传输及多站点 mTLS 配置，避免安全加固触发现有业务的兼容性问题。

PostgreSQL 已合入复制槽失效处理的状态覆盖修复。检查点或启动进程释放复制槽时，旧代码会误用仅对普通后端有效的数组偏移，覆盖另一个进程的状态标志。严重时可能丢失影响清理边界的标志，使 VACUUM 删除备库仍需要的行，即使已启用备库反馈也会受影响。补丁改为仅在逻辑解码标志确实存在时更新共享状态，提交注明回补至 PostgreSQL 14。这是已提交的修复，正式版本是否包含仍须看发行记录。

max_wal_size 是检查点触发阈值的计算依据，并非 pg_wal 目录的硬上限。Christophe Pettus 在 PostgreSQL 18.6 上实测：同一组短时 pgbench 负载把参数从 1 GB 调到 8 GB 后，WAL 写入从 3815 MB 降至 1080 MB。频繁检查点让热数据页反复写入完整页映像，也增加归档与复制成本。调大阈值时还须实测崩溃恢复耗时，结合检查点日志和恢复时间预算确定设置。

pg_clickhouse 0.11.0 与 chdb 扩展 0.1.2 继续处理 PostgreSQL 和 ClickHouse 之间的数据兼容问题。新增的编码选项默认拒绝无效字节，也可选择移除、替换或截断；替换模式在 UTF-8 下使用替代字符。版本还完善区间、嵌套复合类型与参数化 JSON 的映射。pg_clickhouse 同时停止支持 PostgreSQL 13，并调整原始查询接口名称，升级时应核对外部表数据编码和已有调用。

业务表很少变化时，CDC 连接器可能迟迟不推进已确认的日志位置，而同一实例的其他写入仍在产生 WAL，最终造成复制槽积压。AWS 分别介绍 DMS 与 Debezium 的心跳配置，用周期性写入帮助消费端推进进度。两者配置不能直接照抄：DMS 的心跳表无需加入任务选表规则，Debezium 的心跳动作则需确保对应表被采集。排查时应同时观察复制槽与日志保留量，区分低流量造成的停滞和真正的消费能力不足。

Neon 披露了两次由外部依赖故障触发的控制面事故：故障进入自我强化循环，阻碍数据库创建、唤醒和恢复。团队随后用三个月完成三十余项修复，覆盖控制面自身 PostgreSQL 的计划退化与长事务、连接池和 TCP 超时默认值，以及过载时的背压和队列公平性。复盘先量化客户影响，再将每项原因对应到可验证的措施；后续发布按变更风险增加故障演练、渐进放量和回滚检查，避免把依赖恢复当作系统已恢复。

Aurora PostgreSQL 新增查询 Iceberg 与 Parquet 数据的能力，将 DuckDB 嵌入实例，用外部表把湖中历史数据与本地业务表联查，免去预先复制整份数据。功能从 17.11 和 18.6 起提供，需启用 aurora_analytics 扩展并配置 IAM 角色。查询支持谓词下推、列裁剪和缓存，也可通过 Glue 联邦接入外部目录。读查询能放到副本运行；若将结果物化为 Aurora 表，仍须在写实例执行。

PostgreSQL 已合入自连接消除的行级安全修复，并回补到 18、19 稳定分支。同一张表经视图与直接引用访问时，权限检查身份可能不同，对应的行安全条件也可能不同；此前优化器仅按关系标识归组，可能错误合并这些引用。补丁把 checkAsUser 纳入候选分组，阻止跨身份消除连接，并增加视图与表混合查询的回归测试。这项修改维护了优化前后的权限语义，目前属于代码修复进展。

规划 max_wal_senders 时，只数物理备库容易漏算容量。Christophe Pettus 梳理了占用者：默认流式 pg_basebackup 需要两个连接，逻辑订阅还会为正在初始同步的表增加连接，WAL 归档接收程序也在其中。网络中断后未及时关闭的连接，还可能一直占位到超时。PostgreSQL 12 起，这个进程池已独立于普通连接额度；调整时应为备份、同步和断线重连预留余量，并核对备库设置。

一次生产排障把大量临时文件写入定位到单个函数的排序操作。Dinesh Kumar 使用 ALTER FUNCTION 为该函数单独设置 128 MB 的 work_mem，函数退出后恢复调用会话原值。作者报告，在前后均为 1135 次调用的日窗口中，临时文件写入由 150 GB 降至零。这个案例展示了缩小调优范围的方法；内存额度仍按每个排序或哈希操作计算，函数并发运行时仍需评估总内存占用。

Dasha 1.8.1 新增 Log Insights，将一个时间窗口的数据库日志按事件类别和常见消息模板归组，并按语句与计划形态整理 auto_explain 输出。计划树会标出大表顺序扫描、严重的行数估算偏差和磁盘排序，还能对比两个窗口，找出执行计划变差的语句。使用前须配置日志源并启用 auto_explain；分组翻页、计划树和窗口比较依赖存储配置及保存的扫描结果，扫描会由每日清理任务删除。

Percona 比较了五个 Valkey 版本在相同分配器、无持久化条件下的内存开销。厂商称，写入约 63 万个独立小键、值长 16 字节时，每键增量内存从 7.2.14 的 102.48 字节降到 9.1.1 的 64.02 字节，降幅为 37.5%。文章把变化对应到键内联、哈希表布局和短字符串存储，并对比多个字符串键与单个 Hash 的建模成本。结论针对这组小键负载，容量评估仍需保留实际键长、编码与访问方式。

后量子签名会放大证书链与透明度日志的传输成本。Cloudflare 宣布建设支持 Merkle Tree Certificates 的证书颁发机构，目标是在 2027 年初进入 Chrome 的抗量子根库。方案把证书写入追加日志，签署树根并取得独立镜像方的共同签名；客户端若已通过带外更新获得可信树信息，握手时只需传送紧凑的包含证明。公司将提供免费标准签发服务，但生产信任资格仍须经过根库审核。

PostgreSQL 已提交并回补至 19 分支的一项修复，消除了并发 REPACK 中静默丢失大字段更新的风险。此前解码工作进程会先记住 TOAST 表的文件编号，主进程却要等复制数据时才锁表；若期间 VACUUM FULL 重写了 TOAST 表，后续更新便可能被当作其他关系的变更而跳过。补丁将锁定提前到工作进程启动前。这是继新增列默认值问题之后的另一条数据完整性修复，测试 PG19 并发重整时应关注包含该提交的后续构建。

PostgreSQL 逻辑复制应用端的一处竞态已修复，提交说明标明回补至引入问题的 16 分支。应用进程按索引查找目标行时，需要区分副本标识或主键索引与普通索引；此前两次检查之间若发生 DROP INDEX 或 REINDEX，索引身份变化可能让查找失败，并把本应应用的更新当成 update_missing 冲突跳过。补丁将身份判定与索引 OID 一并保存在关系映射中，避免使用不一致的判断。订阅端执行索引维护的团队应关注后续维护版。

PostgreSQL 已合入并行自动清理的一项崩溃修复，并回补至 19 分支。当系统无法再创建动态共享内存段时，并行框架允许退回零工作进程模式，但相应的内存段指针为空。此前自动清理仍在该指针上注册分离回调，导致工作进程崩溃。补丁仅在实际存在并行工作进程时设置共享成本参数和回调，让资源不足时的回退路径能够正常运行。对于开启该功能的 PG19 测试环境，共享内存容量压力不应再触发这一空指针路径，验证时需使用包含修复的后续构建。

PGDG 修复了 RHEL、Rocky Linux 和 AlmaLinux 9、10 的仓库配置包可能永久停留在旧系统小版本的问题。此前仓库 URL 会固化在某个小版本；新配置改用 DNF 的主、小版本变量，随系统升级自动切换。公告同时指出，9.6 自带的 DNF 不识别这些变量，42.0-69 会出现 404，42.0-70 增加了兼容处理。运维人员应更新仓库包，并核对保留的本地配置及 rpmnew 文件，避免包来源与系统版本脱节。

DuckDB 发布 1.5.6，集中回补多项影响查询正确性和恢复行为的修复。包括超长整数字面量转换为 HUGEINT 时被静默截断、共享连接子树的 UNION ALL 返回错误结果，以及隐式包装的多语句执行失败后未在所有路径自动回滚。窗口 Top-N 消除、含空值的排序表达式和 Parquet 时间类型读写也得到修正，WAL 恢复则调整了覆盖重命名前的文件句柄关闭顺序。使用复杂分析 SQL 或多语句批处理的团队，应以回归样例验证更新。

AWS 发布 Aurora 与 RDS MySQL 升级后性能回退的排查指南，强调应用和数据结构未变并不意味着执行计划保持不变。文章从统计信息、优化器成本模型、连接与排序策略、字符排序规则及参数组差异逐层定位，并用执行计划和实际运行指标验证原因。另一个容易混淆的因素是升级后的冷缓冲池：延迟升高可能来自数据尚未预热，而非优化器选错路径。文中建议保留升级前基线，再按具体机制调整统计采样或查询策略，避免把局部回退简单归因于整个新版本。

PostgreSQL 19 beta 4 的并发表重写可以让业务继续写入，但运行成本并不只在目标表。Radim Marek 的实验显示，逻辑复制槽会延长旧行版本的保留，持续更新还会积累解码所需的内存；最后切换文件时仍须取得排他锁，长事务可能拖住收尾。重写也不保证旧快照继续看到原有行。安排在线整理时，应同时观察复制槽、内存和锁等待，并在接近真实写入强度的环境验证，而不能把“并发”理解为没有停顿或额外空间成本。

备库查询为何刚开始就因恢复冲突被取消？Christophe Pettus 解释，两项 max_standby 延迟参数限制的是 WAL 回放能够等待多久，计时与 WAL 接收有关，并不会为每条查询重新发放完整额度。前面的冲突或已有回放积压可能先耗尽预算，后续查询因而很快被取消。调大参数会容许更大的复制延迟；启用反馈也只能避免部分清理冲突，无法消除锁冲突。运维时应结合冲突统计和回放延迟判断原因，再权衡只读查询与备库追赶速度。

面向租户的列表查询通常同时按租户过滤、按日期排序。Chris van Eijk 用 PostgreSQL 17.10、两百万行和规模不均的千个租户测试，发现租户列在前的复合索引能兼顾过滤与排序。更隐蔽的问题来自通过会话设置取得租户身份的 RLS：无参数预备语句可能复用受首个租户影响的计划，强制自定义计划也不能替它创造参数。保留 RLS 作为权限边界，同时显式传入租户查询参数，有助于规划器适应大小租户；效果仍需用实际分布验证。

序列适合产生唯一标识，却不能保证事务回滚后业务编号没有空洞。Chris van Eijk 比较了多租户发票编号方案：为每个租户保留一行计数器，在插入发票的同一事务内更新并返回编号，失败时两者一起回滚。行锁只串行化同一租户的取号，不同租户仍可并行；尽量到事务末尾再分配编号，可缩短持锁时间。实验也说明，直接取最大值再加一存在并发竞争，而可串行化事务需要承受重试。选择方案时要把连续编号与普通技术主键的需求分开。

pgBackRest 2.59.2 增加对 PostgreSQL 19 beta 4 的支持，并修复备份文件被截断为空时的块映射处理、S3 对象版本列表翻页及 Azure SAS 请求等问题。此次适配有测试版边界：beta 4 修改了控制文件和 WAL 格式，旧测试版集群及其 WAL 不再受支持，需按新测试版重新准备环境。使用块增量备份或对象存储仓库的团队，应结合修复清单验证备份链与恢复流程，避免把工具能够启动等同于旧测试数据仍然兼容。

Google Cloud 将 AlloyDB 的 HNSW 索引列式缓存转为正式可用：向量索引可加入读取优化的内存表示，让使用该索引的查询自动受益，适用于运行 PostgreSQL 17 及以上的集群。数据更新使部分缓存失效时，引擎会混合读取有效缓存与磁盘数据，保持结果正确；执行计划可显示两类读取的比例。缓存刷新还可能临时占用相当于索引两倍的内存，因此启用前需要预留容量，并用自身读写比例评估收益。ScaNN 的同类加速仍处于预览阶段。