PostgreSQL 博览 2026-08-24 RSS 订阅

ALTER TABLE MERGE/SPLIT PARTITIONS 已提交进 PostgreSQL 19，收尾阶段却暴露出大量边界情况。Jian He 提交补丁，提议在存在触发器、本地约束、不属于分区索引层次的本地索引、列默认值不一致或访问方法不同时直接报错，因为没有机制重建这些对象。Robert Haas 强烈反对保留：操作全程持有 AccessExclusiveLock，数据全量复制且没有优化，产出的分区既不是源分区的克隆也不是干净的新分区，他主张在发布前回退。

PostGIS 团队发布 3.7.0rc1，3.7 大版本的候选版，相对 beta2 只做缺陷修复，要求 PostgreSQL 14 至 19rc1 与 GEOS 3.10 以上。修复集中在几何输入的健壮性：NURBSCURVE 包围盒遇到非有限控制点会让后端 CPU 陷入拒绝服务，畸形 SRID 前缀和畸形多边形环也能绕过校验，多项问题来自 OSS-Fuzz 与安全扫描。升级后执行 postgis_extensions_upgrade() 即可。

冲突日志历史表的提案里发现一个缺陷：conflict_log_destination 设为 table 时，冲突行里的超大字段值会让逻辑复制中断。根因是 JSON 转义膨胀，escape_json 把控制字符展开成 6 字节序列，190 MB 的值膨胀到约 1.14 GB，越过 varlena 的 1 GB 上限。Amit Kapila 主张省略超大列的值并在原位留标记，Dilip Kumar 据此把每列上限定为 64 KB。

Christophe Pettus 拆解了 PostgreSQL 的计划缓存。简单查询协议下的文本 SQL 每次都要重新解析、重写、规划再丢弃，PostgreSQL 没有跨会话的共享计划缓存，计划只挂在预备语句、PL/pgSQL 和 SPI 这类对象上。带参数的预备语句真正的分岔点在第六次执行：此前用定制计划，之后才可能改用通用计划，不少“什么都没改查询却变慢了”正出自这一刻。文中结论以 PostgreSQL 18 核对。

Neon 的 Carlota Soto 认为传统 OLTP 数据库的笨重来自基础设施层，而不是 PostgreSQL 本身。文章介绍 Lakebase 的存储设计：把 WAL 与 S3 结合，面向 AI agent 的负载，让实例可以随时分支、随用随弃，不必为每个短暂环境准备一整套常驻基础设施。作者的主张是数据库基础设施要匹配 agent 的使用方式，只要存储层选对，PostgreSQL 完全能承担这类场景。这是厂商视角的架构介绍，开销与恢复行为没有给出数据。