PostgreSQL 博览 RSS 订阅

PostgreSQL 修复了 SQL/JSON 查询函数传递大文本时可能读到错误内容的问题。此前，PASSING 把文本值直接交给 JSON 路径执行器，遇到由 TOAST 保存的外部数据时，没有先还原实际文本。新提交统一先解包文本，并增加压缩及外部存储两种回归用例。修复已进入主干及 17、18、19 分支；依赖 JSON 查询处理大字段的应用，可据此补充输入与输出一致性测试，后续升级仍应以正式维护版本为准。

Inngest 披露了一起由账户删除引发的 PostgreSQL 故障：单个事务沿外键级联清理数十张表，随后重复请求排队等锁，占住共享 PgBouncer 的客户端槽位，连接数升至平时约 14 倍。重启连接池没有解除阻塞，取消删除事务后才逐步恢复，部署止损开关时又出现第二轮影响。团队正改用软删除，并把必要的硬删除拆成限速、去重的后台批次；复盘也强调，数据库锁释放后，连接池积压仍可能延长业务恢复。

微软分享了跨数据库迁移后吞吐下降的排查案例：高并发下，一条 NOT IN 子查询反复扫描物化结果，增加硬件只能带来有限改善。确认业务所需的空值语义后，改写为 NOT EXISTS 或左连接反查，再补上以关联键开头的复合索引，才把整表扫描变成少量索引探测。厂商称，在给出的 64 客户端合成复现实验中，吞吐提升超过 800 倍。案例的关键是分别验证计划形态和访问路径，避免把单独加索引无效误判成索引本身无用。

AWS 给出 Aurora PostgreSQL 与 Valkey 的三层成员查询方案：Bloom 过滤器挡住大量不存在的键，精确缓存承接命中，数据库保留权威数据。文章特别区分了过滤器自身的误报率与数据库提交后的传播延迟：新记录尚未进入过滤器时，仍可能被错误判为不存在。因此，方案要求近期写入保护、持久化重试和缓存失效机制，并让最终确认读取具有写后可读保证的数据源。删除通过失效缓存及定期重建清理，性能收益取决于负查询比例与同步机制。

Percona 展示了 MySQL Operator 的跨集群灾备部署：两个站点各自运行 Group Replication，通过 ClusterSet 在站点之间建立异步复制。Operator 负责引导灾备集群、克隆初始数据并维护复制关系；大数据集也可先从备份恢复，再追赶增量。文章演示了计划切换后主备角色互换，以及应用通过代理连接新主节点的流程。这种结构把站内高可用与站间灾备分开处理，部署时仍需验证网络、凭据、数据追赶和故障切换行为。

Cloudflare 复盘了 Pingora 后端路由器的一致性哈希优化。服务器权重和功能组合生成了大量哈希环，团队先将每个哈希点从 8 字节压缩到 6 字节，再用统计分析发现，继续增加虚拟节点收益递减，32 位哈希碰撞还会抵消均衡效果。减少约九成哈希点后，团队同时保留新旧环，按请求和数据中心逐步迁移，避免缓存大面积失效冲击源站。厂商称，这轮改造在全球回收超过 100 TB 内存，相关能力已进入 pingora-ketama。

SILO 20260916 是安全与正确性版本：认证策略拒绝未签名 x-amz-* 并校验预签名 payload，修复 IAM 撤销、多池条件写入、Object Lock、删除标记、multipart 严格列表和复制一致性。版本同步 Console v2.4.1、MC 与 silo-pkg v3.14.1，TLS 曲线交回 Go 1.27 默认值；有 TLS 检查设备必须先评估握手兼容性。

max_notify_queue_pages 是 PostgreSQL 17 引入的启动参数，限制全库 NOTIFY/LISTEN 队列可分配的 SLRU 页数；默认 1,048,576 页，按 8 KB 页约 8 GB。Christophe Pettus 解释它为何取代旧的自发限制，并提醒队列增长常由长期未消费通知的监听者造成。排查堵塞时应同时观察 pg_notify、监听会话、磁盘和重启级 GUC，不能只调大上限。

PostgreSQL 19 与 master 仍有一个分区路由 ON CONFLICT 边界：遇到分区本地的可延迟唯一约束时，插入会走异常路径。该问题在 beta4 冻结前被列为待修复事项，讨论中的补丁还涉及排序规则处理、测试覆盖和 indnkeyatts 检查，说明“索引键列数不同但冲突语义等价”是否可互换仍未定。依赖分区写入与可延迟唯一约束的应用，应在 19 beta/最终版前暂缓升级或自行构造回归用例。

64 位 MultiXactOffset 审查发现，9.3→9.4 pg_upgrade、备机 pg_get_multixact_stats() 和 members 截断都可能产生误导或数据风险。若升级前已发生 multixid 回绕，oldestMulti 处理存在极端静默损坏可能；恢复期间 oldestOffset 未随 WAL 更新会让统计虚高。修复与测试在推进，升级前应检查旧版本状态、备机统计和 pg_multixact 文件。

PostgreSQL hackers 讨论了一份在认证前根据用户输入暴露服务器信息的概念验证补丁。审阅者认为，任何在认证或授权之前处理外部输入的功能都扩大了攻击面，无法靠实现细节把风险降到可接受范围；Tom Lane 明确表示这类方案不可能合入。它不是已发布漏洞或功能，而是一次安全边界审查，提醒扩展和代理设计不要在身份确认前执行可观测操作。

PostgreSQL hackers 发现 WAL_LOG CREATE DATABASE 在故障切换后可能留下错误的可见性映射：堆页清除了 PD_ALL_VISIBLE，VM 页却保持 all-visible，索引扫描可能返回错误。讨论建议 update/delete 路径若堆页原有该标志就注册 VM 清除操作，并为无变化情况使用 REGBUF_NO_CHANGE。问题仍在补丁阶段，使用 WAL_LOG 建库的团队应纳入故障切换测试。

pgAdmin 4 v9.18 带来 29 项修复，并修复 CVE-2026-86861 至 CVE-2026-86864。默认 CSP 收紧，内联脚本改用请求级 nonce，移除 `unsafe-eval`；还修复 Webserver 认证身份伪造、备份/恢复连接字符串注入、Maintenance 密码重定向泄露和 File Manager 符号链接竞态。LLM API 重定向受允许列表约束。升级后回归认证、备份与文件权限。

TimescaleDB 2.30.1 修复 2.30.0 的四类问题：多唯一约束下 `INSERT ... ON CONFLICT` 漏报冲突、单列 bloom filter 的 NULL 冲突处理、`DeferredChunkAppend` 在 LIMIT 未下推时重复返回行，以及 enum 列查询的 cstring 转换错误。涉及冲突写入、分块追加或 LIMIT 查询的应用应在升级窗口回归。

pgColumnar 1.0-alpha4 完善 PostgreSQL 列式表访问方法，重点是布局与跳过：新增 Hilbert 聚类，实测读取 chunk group 比 Z-order 少 1.24–2.04 倍；星型连接默认启用运行时过滤，可跳过不匹配事实表分组；宽表相邻列读取合并，平行索引构建也让 worker 分担不同 row group。原生 PGCN v1 格式不变，但升级仍需执行两项函数更新命令。

ClickHouse Cloud 开放 PromQL 与 TimeSeries 表引擎私有预览，并在 ClickStack 中提供 PromQL。Prometheus remote write 进入专用时序表后，现有查询可通过 ClickStack、Grafana 或 ClickHouse 执行，无需改写 SQL。方案把日志、追踪和指标放到同一平台；接入前要核对保留策略、写入吞吐、查询兼容度和服务区域。

boringSQL 以 PostgreSQL 18.6 逐页演示行锁如何写入元组头：SELECT FOR UPDATE/SHARE、外键检查把锁事务写入 t_xmax，再由 t_infomask 标记；两个会话同时锁一行时使用 MultiXactId，相关文件会随大量行锁增长。文章把可见性、共享内存锁表上限和页面写放在一起，适合作为排查锁争用与 pg_multixact 增长的底层参考；示例事务 ID 不能照搬生产。

pganalyze 面向 SQL Server DBA 解释 PostgreSQL 监控差异：必须主动配置 pg_stat_statements、日志参数、采集周期和保留策略，才能覆盖慢查询排查。文章把 DMV、Query Store 与 PostgreSQL 视图/日志对应，说明如何从总耗时、调用次数、计划变化和错误日志定位问题，并提醒权限、磁盘占用与隐私字段要一起设计。迁移团队可先建立观测基线，再决定是否接入 GUI。

pgAssistant 3.8.0 把 PostgreSQL 分析从一次性检查推进为持续改进闭环：观察、诊断、排序、规划、实施、再采集并衡量结果。结合 Collector，新版 Workload Insights 对比相邻采集，展示建议变化、配置差异、负载趋势、执行时间、调用次数和高影响查询。Executive Plan 继续明确 DEV/OPS 负责人，但项目提醒相关性不等于因果关系；它用于跟踪优化成效，不是实时监控替代品。

PostgreSQL 19 的发布节奏出现调整：Snowflake 梳理了测试期间回退的关键特性与后续计划，指出在线数据校验和转换等改动已从稳定分支撤回，时间段 UPDATE/DELETE 语法也不再按此前状态交付。开发者若根据 beta 行为提前接入，需要重新检查语法、迁移脚本和测试矩阵；最终版本范围以正式发布分支和 release notes 为准。文章还解释了回退背后的审查与稳定性取舍，适合作为升级前的变更清单。

PlanetScale 宣布 TIN 1.0 GA，这是面向 PostgreSQL 的全文检索扩展，使用新索引和 `==>` 运算符，支持布尔、短语、跨度、模糊、通配符与正则匹配。它在持续更新、备份和事务可见性上仍遵循 PostgreSQL 语义，并用 8 GB Wikipedia 数据与 GIN、ParadeDB、pg_textsearch 比较。上线前应在自己的写入负载上复测索引体积、更新成本与可见性。

Percona 在一台装有 4 GiB 热数据的主机上测量 pgBackRest 压缩组合，把节省比例、CPU 秒数和吞吐放在同一条效率曲线上。结果显示 zstd 的拐点在低级别，默认 zstd(3) 约节省 64.7%，每 GB 约 13.8 CPU 秒；lz4(1) 更适合 CPU 或备份窗口紧张的场景，而 zstd(19–22) 和 bzip2 的额外压缩不划算。文章强调数字只用于比较，应先用代表性数据库测量。

PostgreSQL 19 稳定分支撤回了在线启用或关闭数据校验和的整组改动。提交说明称 beta 期间已有多次后续修正，团队选择在 GA 前移除仍可能暴露新问题的代码，仅保留离线校验和初始化、故障日志提示、枚举定义和改写后的文档。已经按在线切换方案设计运维流程的团队，需要删除这条假设并继续为每个数据目录安排离线操作；这次提交是分支代码回退，不能当作正式小版本公告。

PostgreSQL 修复了 pg_multixact 成员截断在页面边界上的页号计算错误。截断点恰好落在页边界时，旧逻辑可能把尚未创建的页传给 SimpleLruTruncate，日志随后误报目录出现 wraparound。修复与其他 SLRU 截断路径一致，先退回上一页再计算清理范围，并回补到 PostgreSQL 19。它不改变多事务语义，却避免维护任务在边界条件下产生误导性告警；升级或回溯补丁时应把该提交纳入分支检查。

PostgreSQL 修复了 ON CONFLICT 对冲突行读取缺少谓词锁的问题。采用 DO NOTHING，或更新条件拒绝该行时，语句可能没有实际写入，原先的冲突探测也未登记读依赖，导致可串行化事务仍出现写偏斜。新实现用查询快照重新读取冲突行，在缓冲区锁保护下获取读锁并检查并发写入。前两类路径自 9.5 起受影响，修复已回补至 14 等受支持分支；这是代码修复合入，正式小版本尚未发布。

PostgreSQL 19 分支撤回了 UPDATE/DELETE FOR PORTION OF 及后续修正，并删除对应发布说明。这套语法原本用于只修改或删除范围列覆盖的部分时间段，自动保留两侧剩余记录。临近下一轮测试版，审查仍在讨论并发更新的处理方式；本次回退同时撤下解析、执行、补全和测试代码，属于已执行的版本范围调整。已经按测试版语法开展验证的应用需要重新评估依赖，不能继续把这项能力视为 19 的既定交付。

PostgreSQL 开发分支为 TOAST 外置大字段加入 64 位对象标识的磁盘指针格式。此前扩宽对象编号计数器之后，这次进一步让块标识列使用 oid8 的 TOAST 表实际保存八字节编号，并同步调整解压读取、关系缓存及 amcheck 校验。新指针比原格式多四字节，类型标记必须与 TOAST 表的块标识类型一致。改动已合入 master 并递增系统目录版本，为大规模外置值提供更宽的编号空间，仍属于开发快照中的存储格式变化。

PostgreSQL 开发分支引入统一的表访问方法索引扫描入口，由表访问方法在扫描开始时选择普通扫描或仅索引扫描的具体实现。原先散落在执行器中的可见性映射检查移入堆表实现，自定义存储因此可以实现不依赖堆表可见性映射的仅索引扫描。约束检查另走专用的元组读取接口，扫描统计也随之调整。这是已经合入的接口重构，为后续批量取索引项和预取数据页准备基础；本次提交本身尚未交付那两项性能特性。

Percona 拆解了 Server for MySQL 8.4.11-11 的缓冲池性能改进。前台线程不再持有 LRU 互斥锁清零整块内存，锁只保护必要的链表操作；后台管理线程提前准备空闲页，并把干净页淘汰计入工作量，减少过度休眠和重复扫描。厂商称，在同一台机器的测试中，这些调整改善了中等并发吞吐，并减轻高并发时的性能下滑。文章同时比较多个 Percona 与上游版本，提示排查吞吐拐点时关注内部锁和页回收，而不只看查询计划。

Cloudflare 为 Workers 增加按单个服务分配的权限，成员和 API 令牌可获得元数据只读、代码只读、编辑或管理员角色。团队可让运维查看设置与指标，同时限制读取代码、创建或删除服务。权限可通过控制台、API 和 Terraform 管理，Durable Objects 随所属 Worker 继承授权；路由管理仍需相应区域权限。功能面向所有客户，可缩小协作账号与自动化凭据的权限，D1、R2、KV 的同类控制仍在后续计划中。

PostgreSQL 开发分支修复了恢复流程错误继承其他节点校验和状态的问题。此前仅在主库离线开启校验和，备库可能开始验证自己并未写入的校验和；备库本地调整也可能被后续检查点覆盖。修复让控制文件保留本节点状态，回放时核对差异，并同步收紧 pg_rewind 与增量备份合并的状态校验。这批改动已进入 master，涉及控制文件版本递增；离线调整仍须逐个数据目录处理，复制不会自动替所有节点切换。

PostgreSQL 的并行 GIN 索引构建会把键值暂存为排序元组，其中键长原先只用 16 位字段保存。遇到超过 65535 字节的键时，长度被截断，后续代码会把键内容误当作倒排列表，可能触发断言、越界读取，甚至向索引写入错误数据。新提交把键长改为 Size，并显式保证数据对齐，兼顾 32 位平台。问题仅涉及并行构建使用的临时格式，同一数据的串行构建不走这条路径；修复已合入 master 和 19 分支。

orafce 为 PostgreSQL 提供 Oracle 兼容函数与工具包，其中 utl_file 允许 SQL 程序操作服务端文件。4.16.9 修复了这一包的路径穿越：旧逻辑信任已登记的目录，却没有在拼接文件名并规范化路径后再次检查实际位置，已获授权的用户可能访问目录范围以外、数据库操作系统账号能够打开的文件。新版对最终路径统一执行安全目录检查。该包默认关闭，已启用它的团队应核对版本、授权与目录配置，并在升级后回归文件访问流程。

Percona 发布 pg_stat_monitor 2.4.0，修复崩溃、内存泄漏与错误统计，并收紧普通用户读取他人查询标识和文本字段的权限。plans 现在只累计实际规划次数，复用缓存计划或执行工具语句不再抬高计数；未设置的 application_name 改为 NULL，名称缺失时的占位字符串也被移除。新版本最低要求 PostgreSQL 14，并删除已废弃的溢出参数。依赖这些字段的监控面板、告警和采集配置需要随升级一起校准。

行锁争用可能在 CPU 和磁盘指标平稳时拖垮订单吞吐，扩容存储或增加只读副本也无法消除同一行上的写入竞争。AWS 新发布的两篇技术文章先从行版本、事务锁和系统视图解释阻塞关系，再演示用 Database Insights 高级模式的阻塞树还原历史等待链。治理方案包括缩短事务、把外部调用移出持锁区间、设置超时，以及把热点计数拆到多行。文章同时给出可复现的库存负载，便于区分临时解阻与应用结构调整的效果。

NTT 的研究用 eBPF 追踪云端 PostgreSQL 的写回路径，发现每个块设备的单一回写线程可能来不及排出脏页，进而触发前台写入限流，而普通磁盘统计难以直接呈现这些停顿。实验在 PostgreSQL 16.4、Linux 5.14 和相同总 IOPS、带宽配置下比较一、二、四块云盘。论文报告，四盘布局相对单盘减少约 70% 的限流停顿，吞吐提高约 23%，最大事务延迟降低约 59%。这些结果提示排障时还应检查内核写回并行度。

PostgreSQL 19 分支已提交回退，移除 pg_get_role_ddl()、pg_get_tablespace_ddl()、pg_get_database_ddl() 及对应发布说明。此前审查仍在讨论权限边界、输出完整性与 pg_dump 的一致性，如今已从设计争论变成明确的版本变更。开发主分支继续保留这项工作，社区将在后续周期重做权限与测试。正在试用 19 测试版的管理工具，应撤掉对这三个接口的依赖。

Query.Farm 在 DuckDB 2.0 开发分支上测试 ADBC 整体查询下推：同一远端数据库中的连接、过滤和聚合可交给远端一次执行，DuckDB 只接收结果的 Arrow 数据流。厂商称，在五百万行 PostgreSQL 数据上，两类查询约快 10–11 倍，收益主要来自减少数据搬运。该能力仍依赖开发版本和测试分支，只有通过语义检查的查询才下推，不支持的部分回退本地执行；使用前也要评估远端数据库增加的计算负载。

低写入负载下，等待 WAL 归档段触发传输可能拉长跨区复制延迟。Oracle 介绍了 OCI PostgreSQL Warm Standby 场景的替代路径：通过 pglogical 扩展持续传递变更，避免仅靠缩短归档超时增加小批量传输成本。厂商称，在跨三个大洲的案例中，变更约 1–2 秒可见。这里仍是异步逻辑复制，应用必须规划写入归属、冲突处理和最终一致性，不能把该数字理解为同步提交保证或所有跨区部署的固定表现。

ClickHouse 26.8 是新的长期支持版本，除了查询性能优化，还处理了物化视图初始化时容易遗漏的并发写入。默认启用的原子 POPULATE 会协调快照与后续订阅，填补历史数据装载和增量接收之间的空隙。新版本同时提供后台查询、更完整的中文分词及流水线式 SQL。已有服务升级时，可重点回归并发插入下的视图结果、后台任务生命周期和分词后的检索效果；发布说明中的基准提升仍需结合自身数据分布验证。

Moovit 的数据平台改造从逐条核算查询 CPU 消耗开始，把大规模转换迁往 EMR 上的 Spark，稳定报表保留在 Redshift，探索查询交给独立的无服务器资源。团队先清理无效任务，再改写重度去重与数据交换步骤，并用行数、用户数和业务指标验证迁移前后的结果。厂商称，这套分工使整体成本降低 33%，而不是依靠一次性扩大集群。案例也展示了逐步缩容和逐轮性能检查的过程，适合已有数仓出现转换任务与查询争抢资源时参考。

Cloudflare 在 Pingora 缓存链路中试验 Zstandard 转码：符合条件的未压缩文本在写入缓存时压缩一次，压缩表示可继续在分层缓存间传递，发送给客户端前再还原。厂商称，测试语料取得约 2.8 倍压缩比，并在所测负载下控制住 CPU 开销。方案仍是原型，实验只覆盖特定状态码、已知长度和大小门槛的对象；范围请求、源站已压缩响应及更广语料仍待验证，不能据此推算整个缓存网络已经节省的容量。