PostgreSQL 博览 2026-09-27 RSS 订阅

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 的同类加速仍处于预览阶段。