PostgreSQL 博览 RSS 订阅

PostgreSQL 的 SCRAM 口令每次重设都会生成新盐，即使输入的密码没有变化，存储的认证密钥也不同。Christophe Pettus 用 PostgreSQL 18.6 与 PgBouncer 1.26 实测，静态认证文件中的旧密钥会因此失效，但已有连接仍能工作，故障要到连接池再次建立后端连接时才暴露。文章说明，自动化配置不能只在密码变更时更新文件；使用动态认证查询可避免用户密钥副本过期，同时还须安排查询账号自身的认证方式。

ParadeDB 0.26.1 修复了搜索扩展的行级安全边界：此前自定义扫描下推过滤条件时，没有遵循 PostgreSQL 的安全检查顺序，部分表达式可能先在无权读取的行上执行，再通过报错泄露数据。修复为过滤下推增加安全判定，无法安全下推的条件交回常规过滤，或放弃相应自定义扫描。版本还修正连接查询中丢失 WHERE 条件，以及通用计划参数所在内存过早释放的问题。使用 RLS、连接检索或预备语句的部署应优先核对这些查询路径。

PostgreSQL 代理 PgDog 0.1.61 修复了后端连接恢复时意外提交流水线请求隐式事务的问题，并把 WAL 时间线纳入升主识别，避免旧主仍可连接时误判拓扑。版本还修正重分片复制的日志位置边界，并把外键校验纳入迁移流程；显式事务只在需要时连接相关分片，以减少连接池占用。插件接口改为逐条处理语句，属于不兼容变化。使用分片、故障切换或自定义插件的部署，应分别核对事务结果、切换行为与接口适配。

Amazon Aurora 在 PostgreSQL 14–18 的五条版本线上发布稳定性补丁，修复存储卷达到最大尺寸时，存储元数据可能使数据库无法再次启动的问题。同批更新还修复 Storage Daemon 内部日志增加存储占用的缺陷，涉及实例能否恢复服务与底层空间消耗两个运维环节。此次更新的重点是存储可靠性，使用相关版本的团队可据此核对维护计划，并把接近容量上限的实例纳入升级与恢复验证范围。

Vitess 24.0.4 修补多条严格表权限检查的绕过路径：无法确定访问表的语句改为拒绝执行，DDL、EXPLAIN、SET 等语句内嵌的读取也纳入权限校验。配置证书吊销列表后，TLS 会话恢复和不同 SSL 模式都会执行检查；证书链或配置无法验证时拒绝连接。版本还移除了旧 vtctld HTTP 管理接口。升级需核对受影响语句与证书配置，混合版本期间，旧 vtgate 保存的含子查询设置可能被新 tablet 拒绝。

AWS 发布 Lambda Web Functions，让监听端口的 HTTP 应用直接部署到 Lambda，无需改写为事件处理器。每个执行环境最多并发处理 128 个请求，CPU 按实际使用时间计费，等待数据库或外部接口时不按整段墙钟时间计算 CPU 费用，内存仍持续计费。新形态可跨区域复制代码并按延迟路由，也支持按修订分配流量。首发采用 Arm64 与 Node.js 24，覆盖五个区域，并可连接 VPC 内资源。

PostgreSQL 已提交提前聚合的跨类型分组修复。小整数与整数连接时，优化器此前可能套用另一类型的相等运算符，把不相等的值并为一组，产生错误结果。补丁只允许同类型表达式复用分组规则，同组还修复了外部表与分区连接的处理，避免部分聚合结果被当作普通扫描，并补齐子关系的排序键。三项提交均标注回补至 19，涉及这些查询的测试环境应重新核对结果与执行计划。

PostgreSQL 的 SSL 配置重载失败时会保留旧配置，但 PG 19 的 SNI 开关此前可能已经切到新值，导致后续握手访问不存在的主机配置。已提交的修复让握手使用成功加载时的开关值，并复制相关参数，避免重载失败后继续引用失效内存；同组还补上 TLS 销毁与初始化失败时的资源清理。四项修复均标注回补至 19，测试环境可重点复核证书、主机配置热更新后的新连接与回退行为。

Radim Marek 以 PostgreSQL 18.6 的两百万行实验说明，TABLESAMPLE 按物理地址选行。SYSTEM 按页抽样，减少读页，却会让按时间装载的数据成簇入样；BERNOULLI 按行抽样，仍须访问全部页。固定随机种子也无法保证更新或表重写后抽到同一批记录。需要稳定且能保持外键关系的测试子集时，可对主键与相应外键使用同一哈希规则，但要付出全表计算或维护表达式索引的成本。

全文检索扩展 pg_fts 的 1.11、1.12 版本修复多处索引缺陷。并发刷新待处理列表曾可能丢失新行，已删除行也可能残留并误命中；截断锁与页面回收竞态还会导致崩溃。升级不改变磁盘格式，已有索引中的异常条目需用 REINDEX 清理。1.12 缓存词典索引，减少共享缓冲区的反复加锁和访问；词典缓存重建期间取消查询仍可能泄漏内存，常驻会话需留意这一已知问题。

ScyllaDB 2026.3.3 修复多处影响恢复与存储可靠性的缺陷：回放损坏日志段时，大事务片段缓存现按分片隔离，避免混入其他分片的数据；刷新 SSTable 目录时，也只处理已完整创建的文件，防止误删仍在生成的组件。更新还处理了日志段分配超时后无法释放、反复发生可阻塞写入的问题，并为 S3 读取重试加入退避与次数上限。正在使用对象存储或执行节点维护的集群，需关注这些恢复与运维路径。

Turso 0.8 为 BEGIN CONCURRENT 加入组提交，让一批事务共用一次日志 fsync，降低并发写入等待。事务仍须等日志刷盘才可见，持久性约束不变。厂商称，同配置微基准中的吞吐与尾延迟有所改善，但单连接写入仍不及 SQLite，同一行的写冲突仍需重试。该版还补齐窗口函数和递归查询，让全文索引适配 MVCC；Turso Cloud 的 MVCC 仍处技术预览阶段。

PostgreSQL 主线修复了哈希索引在桶分裂期间启动扫描时漏行的问题。旧代码读完第一个桶后可能提前结束，没有继续读取另一半；触发还要求分裂开始后插入了匹配记录，且首桶最后读取的页含匹配项。补丁统一正反向跨桶逻辑，并加入可复现测试。提交标注回补至 14 分支，使用哈希索引的实例应关注后续维护版；回归验证可覆盖并发插入以及正反向扫描这两类路径。

PostgreSQL 已提交一组优化器正确性修复。表达式缩减为输入列时保留类型修饰与排序规则，避免 CASE、NULLIF、COALESCE 改写影响排序或分组；同时修复分区虚拟生成列的非空误判，并恢复 ON CONFLICT 对简化索引表达式的匹配。提交均标注回补至 19，其中旧版 CASE 与 NULLIF 的问题因兼容性顾虑暂不回补。测试 PG19 时需以包含修复的新构建复核。

Now-Next 在 PostgreSQL 17、18 上实测发现，一租户一分区配合仅在 RLS 中设置租户条件，会把小查询变成大量规划与加锁工作。其千分区样例从显式租户条件下约 0.25 毫秒升至约 77 毫秒，每次查询持有约 2,003 个关系锁，并发时耗尽共享锁表。提前写明租户谓词可在规划阶段裁剪分区；测试用小表和热缓存，反映的是固定开销，不能直接用于容量规划。

Pettus 对照 Aurora、pg_lake、ColdFront 与 pg_clickhouse，指出湖仓查询的关键差别在于由哪个引擎掌握规划权。完整下推可把连接交给湖端；部分下推只传递扫描，本地规划仍可能缺少统计信息。类型与排序规则也会改变执行路径，pg_lake 通过独立进程运行 DuckDB。这份比较依据项目文档，并未同场跑分，选型时应检查普通表与湖表混合连接的执行计划，再核对写入与事务边界。

MariaDB 基金会为测试框架 TAF 加入 PostgreSQL 插件，把安装、实例生命周期、SQL 执行、负载运行与结果报告接入同一流程。插件可运行 HammerDB 的 TPROC-C、TPROC-H 及 sysbench 负载，并生成可复现的配置文件与性能剖析。PostgreSQL 的负载配置仍标作测试版；sysbench 必须编入对应的 PostgreSQL 支持，否则框架会告警并跳过。

Docker Engine 29.9.0 修复了加密覆盖网络的一处保密性缺陷：内核加密规则配置失败时，部分数据包可能以明文发出。接收端会拒绝这些包，因此影响主要是单向流量与未完成握手，而非已建立连接的全部内容。新版同时通过更新 Go 修复多项 HTTP/2 拒绝服务问题，并修正镜像可运行却缺少导出所需层文件、无根模式连接泄漏等故障。使用 Swarm 加密网络的团队应结合更新安排检查节点网络行为。

PostgreSQL 已合入两项截断检测修复：pg_verifybackup 会确认 gzip、LZ4、zstd 压缩备份完整结束，pg_restore 则补验 LZ4、zstd 转储的最后一帧。此前解压过程没有报错，也可能接受被截断的数据。补丁同时处理 zstd 残留输出，增加多种格式的回归测试。两项提交均注明回补至 19 分支，备份使用者需留意后续构建，并验证实际恢复结果。

PostgreSQL 后端异常退出后，主进程可能仍保持原有 PID，所有会话却已断开并重新执行崩溃恢复。Shridhar Khanal 从两类 SIGHUP 日志入手，区分正常重载配置与子进程被信号终止：后者会触发共享内存重置和 WAL 重放，不能只凭服务进程仍在就排除故障。对单个后端执行 kill -9 也可能波及整库；处理慢查询应先取消语句，必要时再通过数据库接口终止会话。

pgJDBC 发布 42.7.14，修复两类有明确触发条件的安全问题。42.7.11–42.7.13 在 requireAuth 排除全部认证方法或未给出有效方法时，会将限制视为未设置，可能接受明文密码认证；新版拒绝连接。42.7.4–42.7.13 在应用写入短于声明长度时，可能用同连接先前的 SQL 和参数字节补齐，造成内容泄露；新版改为补零。升级时应检查认证白名单与自定义流写入实现。

Citus 增加数据节点后，单个协调节点仍可能先耗尽解析、规划与转发能力。StackGres 1.19 引入查询路由器，把不承载分片的 Citus 节点作为独立入口，并由 Kubernetes 服务分散连接。协调节点继续处理 DDL 和拓扑变更，路由器则同步元数据并参与参考表复制。厂商在特定单行查询测试中，称三个路由器将吞吐从约 55 万提升到 143 万次每秒；新增参考表副本期间仍可能阻塞写入。

Percona 工程师对 MySQL 二进制的性能剖析引导优化进行实测，发现训练数据比打开编译开关更关键。只用窄范围 sysbench 负载，会把清理、刷盘和其他执行路径当作冷代码；高并发采集还可能扭曲热点或破坏计数。合并功能测试与适度并发训练后，收益仍会随竞争加剧而缩小。作者测得低并发一度提升约 12%，高竞争下不足 2%，说明构建优化必须用真实负载复核，不能直接套用单项基准结果。

Cloudflare 为 Workers 与 Durable Objects 开放按需 CPU 和内存性能剖析，可在控制台查看火焰图，也能下载采样文件继续分析。普通 Worker 从正在运行的实例中抽样，有状态对象则可按名称定位到具体实例，帮助追踪热点函数、分配开销及内存不足原因。采样需要实际流量，内存视图只覆盖捕获期间的新分配，无法追溯启动期或此前发生的异常；持续自动剖析仍是后续计划。

并发更新触发行资格重检时，PostgreSQL 的执行器可能重复初始化运行期分区裁剪状态，把父执行器仍要使用的内存改挂到短命的重检上下文。重检结束释放上下文后，后续裁剪便可能访问已释放内存。上游已合入修复，通过初始化标记复用既有状态，提交注明回补至 PostgreSQL 18。问题在会覆盖已释放内存的调试构建中更容易显现；生产构建是否触发则取决于内存上下文的实际释放和复用过程。

Kaarel Moppel 用约 800 小时测试比较 PostgreSQL 18.6 与 19 Beta 3、Beta 4，在两家云平台的多种机器上运行 pgbench 和类 TPC-C 负载。固定事务量的总体执行时间约缩短 3%，部分插入语句改善更明显，更新语句则未普遍加速。测试以能放入内存或轻度访问磁盘的数据集为主，并关闭自动清理。这组结果为升级评估提供了可复现脚本，但不同查询的差异也说明，不能把总体均值直接套到自己的生产负载。

pgEdge 的 Andrei Lepikhov 分析 PostgreSQL 精确数值类型的执行开销：变长存储、每个值自带标度，以及运行时确定结果精度，使拆解元组、分配内存和比较数值都需要额外工作。文章对照 DuckDB 的定宽整数表示，说明更快的十进制运算往往伴随精度上限或不同的除法语义。优化方向因此不只在算术指令，还包括解包、内存分配和中间结果处理；评估替代类型时，需要连同精度、溢出与输出成本一起比较。

PlanetScale 的 TIN 全文检索扩展继续补齐排序与分词能力。1.0.6 让按相关性排序后再按时间或主键打破平局的查询，也能使用 block-max 跳过无关文档，避免给全部命中结果评分；此前的 1.0.4 已加入 18 种语言的词干处理，启用时需要重建索引。厂商称新版本在其基准中明显提速，并同时公开默认评分与完整评分结果。默认模式会省略高频词的评分贡献，比较速度时必须保持评分语义和硬件条件一致。

AWS 为 Aurora PostgreSQL 与 RDS for PostgreSQL 增加数据外泄和破坏行为检测。新的数据活动能力持续分析查询模式，在登录异常之外识别取得有效凭据后的可疑操作；AWS 表示无需安装代理或修改数据库配置。该能力作为登录活动保护的附加项，可通过控制台、API 或基础设施配置为账户及组织启用。覆盖范围是已提供 RDS Protection 的商用区域和美国政府区域，采用前仍需核对数据库版本支持。

Vault 2.1.2 修复插件越出配置目录执行、异常策略路径及大小写变体绕过精确拒绝规则等问题，同时收紧 ACME 对未经验证身份字段的签发。升级会改变部分资源名的 ACL 匹配：相关规则必须使用小写路径，旧的混合大小写拒绝规则可能失效；异常历史策略也可能不再授予权限。运维团队需先检查策略和插件目录，再安排升级。发布说明还列出尚未覆盖的认证后端，不能把这次修复理解为所有大小写绕过情形都已消除。

PostgreSQL 已提交故障转移复制槽的同步修复：主库删除最后一个逻辑槽后，若很快以同名重建，备库可能把旧的 WAL 起点保存到新槽。后续同步因此报错，连带阻断其他故障转移槽，提升后的槽也无法继续解码。补丁记录逻辑解码最近启用的位置，在创建本地槽后核对远端起点，不合格时等待下一轮重新获取。提交注明回补至 19；这一修复针对动态启停与槽重建之间的竞态，依赖逻辑复制容灾的部署需关注正式版本收录情况。

PGX 发布 pgx-bm25 1.0.0，以 PostgreSQL 原生索引访问方法实现 BM25 全文检索。扩展使用 C 编写，通过 PGXS 构建，索引更新接入 WAL、崩溃恢复与复制，并支持 VACUUM 清理。查询可把相关性排序和结果数量限制交给索引，配合分块跳过算法减少不必要的评分，也能为多个文本字段设置不同权重。首版支持 PostgreSQL 17、18，19 测试版仍处于验证范围；它为事务库内的关键词排序提供了新选择。

Igor Suhorukov 展示了面向 PostgreSQL 19 的 pg_vexec 实验：利用扩展接口加入批量扫描、聚合、连接和排序，让向量路径参与优化器的成本选择，也可回退原执行方式。与此前需要内核补丁的 Cloudberry 移植不同，这次单机扩展及 ORCA 适配可在原版服务器上运行；另一个扩展用 Arrow Flight SQL 传输结果。作者公布了回归测试和不同查询的实测结果，也列出变慢的场景，仍需继续优化与验证。

Neon 为 Lakebase Search 加入 lakebase_tokenizer，把同义词和停用词从服务器文件搬进数据库表。托管数据库用户可通过 SQL 定义词表、创建检索配置，再把生成的 tsvector 交给 GIN 或 BM25 索引；词典也随数据库分支一同复制，便于隔离验证。文章用缩写、变音符号和自然语言查询说明，分词不仅决定能否匹配，也会改变词频统计与排名。此次变化让托管环境也能维护自定义词典，仍需按语料验证效果。

Argo CD 3.5.4 集中修复多项安全问题，包括 Kustomize 远端引用触发命令执行、Jsonnet 读取仓库服务器文件，以及删除钩子绕过项目限制。部分攻击路径只要求读取已有应用，并不需要修改或同步应用的权限；限制服务器出网也不足以阻断本地传输路径。更新同时改变兼容行为：Kustomize 不再使用指定的 Helm 配置目录，超大 OCI 清单会被拒绝。团队应按所用版本分支升级，并核对依赖自定义 Helm 插件的构建流程。

DNS 根区计划于 10 月 11 日切换密钥签名密钥，启用标识为 38696 的 KSK-2024。执行 DNSSEC 验证的递归解析器若没有信任新密钥，正常网站也可能变得无法访问。Cloudflare 介绍了基于信任锚哨兵协议的预检方法，可区分已信任、未信任与无法判断；软件升级或迁移后，还要确认自动学习的信任状态没有丢失。本次轮换继续使用原有签名算法，网站普通域名配置通常无需调整，检查重点是验证解析器实际采用的根信任锚。

PostgreSQL 已提交 B-tree 去重修复：bpchar 比较会忽略尾随空格，某些等值数据却有不同的存储表示；去重把它们合并后，仅索引扫描可能返回错误值。补丁为相关操作符类禁用去重，并在主线与 19 分支处理 oidvector 的类似问题。维护者明确要求重建受影响的 bpchar 索引，单纯更新程序无法修正已有索引。补丁注明回补至 14；这是已提交修复，尚不能等同于正式小版本已发布。

PostgreSQL 已合入一项逻辑解码修复。事务进入失败状态后仍可能持有事务 ID，逻辑日志模式的更新必须延后；旧处理却只在事务中止路径检查，最终清理没有重新应用变更。连接随后开始的新事务便可能缺少逻辑解码所需的信息，订阅端因此静默跳过数据变化。补丁把状态更新移到事务 ID 清除之后，覆盖显式事务失败后再回滚的边界，并注明回补至 19。依赖逻辑复制或 CDC 的团队应关注后续正式版本收录情况。

pgBackRest 2.59.3 修复了未检查随机数生成结果的问题：若系统熵不足导致调用失败，旧版本可能以残留内存生成加密子密钥或盐，使备份加密强度不足。问题只涉及加密仓库，但升级程序本身不会轮换已经写入仓库元数据的子密钥，后续备份也会继续沿用它们。项目提供了检查方法；确认存在弱子密钥时，需要按公告建立新的仓库与备份链。运维团队应同时核对程序版本和已有密钥，不能把升级完成视为历史风险已经消除。

将商店、客户管理和账单库汇总到一个分析库，逻辑复制能够搬运数据，却不会自动改写模式名或同步表结构。Dimitri Fontaine 用 PostgreSQL 18 的可复现实验，说明发布端应预先划分模式，新增列与删除列也需要安排两端执行顺序。调整行过滤和列清单不会清掉订阅端已有数据；汇总库再输出 CDC 时，还须明确是否包含复制来源的变更。文章把过滤、二次解码和结构演进放在同一流程中，便于在上线前验证数据边界。

索引顾问常用 HypoPG 比较优化器成本，但成本下降不代表查询一定加速。Prateek Arora 在 PostgreSQL 16 上使用约 7 GB 的 IMDB 数据，实际创建建议索引并执行查询：179 项可测建议中，128 项至少快 15%，32 项至少慢 5%，其中 7 项耗时超过原来的两倍。行数估算错误会让新索引诱导优化器选择更差的连接计划，而假想索引仍依赖同一套估算。评估工具输出时，应在可控副本上验证真实执行时间与计划。

多个计算引擎共享 Iceberg 表时，目录必须协调元数据指针更新，避免并发写入覆盖彼此的结果。Google Cloud 介绍了其湖仓运行目录的实现：以 Spanner 的可串行化事务支撑乐观并发控制，通过 Iceberg REST 接口提供一致的表发现与提交路径，并在区域内提供高可用。目录还可按访问请求发放临时存储凭据，让引擎读取同一份数据而不必长期保管云存储密钥。文章说明的是现有目录的架构与权限边界，可用于评估多引擎湖仓的控制层。