PostgreSQL 博览 RSS 订阅

Nikolay Samokhvalov 报告了 PostgreSQL 19 外键快速路径批处理的三个缺陷：重入的外键检查会越界写入、子事务里的违规被漏掉、批处理过程中留下孤立行。Amit Langote 给出两个补丁，前者为每个条目加刷新标志并调整操作顺序，后者把批处理限制在顶层事务并加上缓存范围的重入保护。测试确认三个缺陷都已修复，现在会正确抛出外键违规而不是静默通过。补丁改用边界检查而不是重排来保留测试覆盖，计划在最终评审后提交。

AWS 数据库博客用一套 CloudFormation 模板把 Oracle 迁往 Amazon Aurora PostgreSQL 的过程拆成两步。第一步用 DMS Schema Conversion 把 Oracle 的模式、数据类型和 SQL 代码转成 PostgreSQL 兼容形式，多数对象自动完成，需要人工处理的会被单独标出；第二步用 DMS 搬运数据。模板会一并部署 Oracle RDS、Aurora 集群和复制实例。

Tiger Data 讨论统一命名空间（UNS）架构下历史库的表结构该怎么定。作者的判断是标签变动在 UNS 里属于常态，按资产建宽表、把标识编码进列名的做法因此不再适用，改个名字就要付出 ALTER TABLE 的代价。推荐做法是两张窄表：一张命名空间表用代理键存 ISA-95 层级，一张 tag_history 通过外键引用它。标识与路径解耦之后，重命名标签只是一次 UPDATE，工厂重组和标签停用都不必迁移数据。

Apple 把自家的容器工具 container 发到 1.0.0。项目 README 要求 Apple Silicon 和 macOS 26，底层依赖 Apple 的 Containerization Swift 包。macOS 开发机此前多靠 Docker Desktop、Colima 和 OrbStack，官方工具如果稳定，会改变本地容器运行时、虚拟化和网络的开发体验。本地数据库测试可以先观察它的网络、卷与 OCI 兼容性。

GitHub 提前公布了 npm v12 的破坏性变更清单，给生态留出迁移期。真正的风险不在变更本身，而在持续集成镜像悄悄升级 npm，或者开发者本地与生产构建用的 npm 大版本不一致。npm 是规模极大的软件供应链入口，即使变更不涉及安全漏洞，也会影响构建、发布和依赖更新机器人。建议逐个检查 Node 项目的 engines 字段、lockfile、CI 基础镜像和发布权限，并给发布链路固定 npm 大版本。

工作流自动化平台 ServiceNow 通知客户，一个漏洞让部分客户数据暴露在公网上，未经授权的外部访问可以读到本应受限的信息。公司称已经联系受影响的客户，但暴露范围、持续时间和具体涉及哪些客户仍不清楚。ServiceNow 被大量大型企业用来自动化内部业务流程，这些系统里沉淀的运营数据敏感度很高，一次事故的影响面通常不小。对同类企业软件的使用方来说，值得借这次事件复核数据分级、外部可达性和访问日志的留存周期。

Dalibo 发布 PostgreSQL Anonymizer 3.1。这个扩展用动态、静态、副本、备份等六种策略隐藏数据库里的个人信息与商业敏感数据，3.1 在此之上加入本地差分隐私：用广义随机响应机制处理调查数据和分类值，观察者即使掌握辅助信息也无法高置信度还原原值，聚合统计仍然可用。该版本还修复了一个可导致权限提升的严重漏洞，PostgreSQL 14 上的实例风险最高，官方建议立即升级或先应用临时缓解措施。

TimescaleDB 2.27 的重点是减少分析操作中不必要的解压工作。压缩数据上的 UPDATE 和 DELETE 现在也用布隆过滤器在解压前做批次剪枝，厂商称最高提速 160 倍；UPSERT 借助复合布隆过滤器提高冲突检测效率，Hypercore 向量化执行引擎能内联处理更多过滤表达式，连续聚合刷新提速 30% 到 2 倍。此外新增连续聚合的合并刷新。该版本同时宣布弃用 PostgreSQL 15，支持将在 2.28 结束。

PostgreSQL 19 Beta 1 发布之后，AWS 把它放进了 Amazon RDS 的 Database Preview Environment，托管用户不必自建整套测试栈就能验证应用与扩展的兼容性。这是预览而不是 GA：预览环境的实例最长保留 60 天，快照也只能在预览环境内部使用。计划升级到 19 的团队可以借此提前跑一遍逻辑复制、序列同步、SQL/PGQ 和常用扩展组合，把云上行为与自建环境的差异记录下来。

Cybertec 的 Christoph Berg 记录了温哥华的 PGConf.dev 2026。会议既有社区讨论，也有周五由与会者投票定题的非正式环节。重点包括与 Bruce Momjian、Tom Lane 等早期贡献者的圆桌回顾，Robert Haas 介绍 PostgreSQL 19 的规划器提示，以及把透明数据加密并入内核的进展讨论。其他议题还有索引预取、时态查询，以及正在提交给 SQL 标准委员会的 key joins。

Microsoft 安全团队分析了一批以 AI 品牌为诱饵的社会工程活动：攻击者利用开发者急于试用新工具的心理，用仿冒的 AI 工具页面窃取凭据。官方强调这是品牌滥用，相关 AI 服务本身并未被攻破；TechCrunch 的报道把讨论延伸到被篡改的 Microsoft 开源工具与 AI 开发者密码泄露。建议在安装 AI 命令行工具、编辑器扩展和 MCP 服务器前先核对发布者、签名与发布产物，并收敛共享 API key 的暴露面。

安全团队常见的困境是知道有威胁却难以快速把它变成边缘规则。Cloudflare 把威胁情报做成 WAF 可以直接引用的实时字段，按行业、地区和威胁团伙等维度匹配请求，官方称检测在边缘节点本地执行以控制延迟，同时保留 Security Analytics 的可见性。这样一来情报就成了 API 和 Terraform 能够编排的对象，规则可以随情报更新自动生效。落地前建议先在日志和分析里观察一段时间，确认误杀率可以接受再切换到拦截模式。

很多组织的真实风险不在活跃仓库，而在没人维护却仍被部署、被引用或仍存有密钥和旧依赖的仓库里。GitHub 新增的定期代码扫描针对的正是这些闲置仓库：它是组织级的 Advanced Security 全局设置，作用于 code scanning 的默认配置，不需要为每个仓库单独打开。管理员可以借此把归档仓库和遗留部署对应的仓库一并纳入安全覆盖，并重新核对哪些闲置仓库仍然出现在生产依赖链里。

Postgres 的水平扩展一直缺一个像 Vitess 那样的编排层。Supabase 把 Multigres 定位成 Postgres 的可扩展操作系统，目标覆盖分片、连接池、自动故障转移和备份编排，v0.1 Alpha 只开源、不面向生产，更像早期路线公布和征集合作。判断它能不能用要盯几处边界：分片键怎么选、跨分片事务怎么办、连接池放在哪一层、故障转移语义、备份恢复流程和扩展兼容性。

AWS DMS 的模式转换能搬走大部分表结构，存储过程、函数和触发器这类复杂 PL/SQL 对象却往往要人工重写。AWS 的方案把 Bedrock 上的 Claude Sonnet 4.6、Strands Agents 框架和 AWS Knowledge MCP 服务器串起来：读 DMS 评估报告，从 Oracle 取源码，用模型转换，经 Lambda 部署到 Aurora PostgreSQL 做校验，再逐个对象跑九项自动测试，厂商测得的平均置信度是 92%。

提交 a0b6ef29a 让带非易失约束的域也能走快速默认值，代价是行为不一致：给空表加一个带域默认值的列时，约束检查报错会让 ALTER TABLE 失败，等价的 CREATE TABLE 却能成功。Tom Lane 认为这对 pg_dump 的可靠性构成隐患，而且该优化处理域约束错误和其他运行时错误的方式并不一致。Andrew Dunstan 赞成在 19 里撤销，完整修复要等新的表访问方法回调，留给 20。

pg_background 把 SQL 丢进独立的后台 worker 执行，事务生命周期与主事务分开，适合审计写入、缓存预热、建索引这类不该拖慢主流程也不该跟着回滚的活。2.0 做了三件事：函数名去掉 _v2 后缀，取消与等待合并成带可选参数的函数；收回所有函数的 PUBLIC 权限，改用 pgbackground_role 分配，worker 以发起者身份运行；新增超时统计与结构化错误字段。已在 14 到 19 beta 上测试。

Chao Li 发现 psql 的若干描述查询直接引用 pg_foreign_server 等目录表，没有加 pg_catalog 限定。攻击者可以在自己的 search_path 里建一张同名表，污染描述命令的输出，让它显示伪造的服务器名。问题来自最近为订阅描述补充服务器信息的几次提交，一共四处：两处出现在 19，另外两处更早、可能要回补。修法是把目录引用改成完全限定，确保查的始终是系统表。

Troy Hunt 以经手过的上千起数据泄露为样本写道，行业成熟并没有让披露变快，通知延迟反而比以往更糟。对受影响的人来说，知道自己何时被波及、被泄露了什么、该做哪些补救，与修好漏洞同样要紧，而这部分恰恰不是技术能替代的。他的建议是提前准备好泄露通知的操作手册：证据保全、影响面判定、用户通知口径、凭证轮换、法务边界，以及对外状态页的更新节奏，等到出事再临时决定就来不及了。

Peter Geoghegan 放出索引预取的第 26 版补丁。最显眼的新增是 gistgetbatch，让 GiST 扫描也能做索引预取，效果与 nbtree 相当，例子里查询提速二十倍以上。补丁还清理了一批与 slot 相关的实现，仅索引扫描不再需要缓冲元组的 slot；接口上移除了 IndexFetchTableData 结构，新增 amcanmarkpos 声明标记与恢复能力。GiST 对使用距离操作符的有序扫描仍关掉预取。

Tomas Vondra 排查调大 join_collapse_limit 之后的问题时，跟踪了一个十二表连接查询的内存分配：规划阶段吃掉约 2.5 GB，其中 find_mergeclauses_for_outer_pathkeys 占 671 MB，generate_join_implied_equalities 占 660 MB，合计约三分之二，原因是反复生成条目却不释放。Tom Lane 的小补丁把内存降到 1.8 GB。

Jane Street 的工程师写了一篇实践总结：现在做产品设计，用 Claude Code 的时间比用 Figma 还多。差别在于产出不是静态稿子，而是可以直接交互的原型，改动能立刻跑起来看效果，设计探索的循环因此变快。这说明智能体工具的影响面正从 IDE 扩散到产品与设计。不过要补上视觉走查、浏览器测试、无障碍和代码评审，否则原型会直接变成没人管的生产代码。

Nikolay Samokhvalov 在 PostgreSQL 19 新增的外键检查快速路径里发现三处问题。这条路径把外键检查攒成批处理，但延迟刷批时会执行用户定义的转换函数或操作符，于是给了重入的机会：满批刷新时重入会造成越界写入并可能崩溃；子事务回滚会丢掉父事务缓冲的行，导致外键检查被跳过、孤儿数据得以提交；跨表重入还会让哈希迭代漏掉条目。三者都能由普通用户用带隐式转换的自定义类型复现。Amit Langote 已确认并开始排查。

持久化执行本来是后端基础设施的一类模式，通常靠 Temporal 这样的独立引擎实现。微软把它做成了 PostgreSQL 扩展 pg_durable：工作流直接用 SQL 定义，每一步都记检查点，崩溃、重启或某步失败之后可以从断点继续。项目支持 PostgreSQL 17 和 18，采用 PostgreSQL 许可证，文档指向 Azure HorizonDB。它短期未必能替掉现有队列引擎，但和事务边界、连接池的配合值得先评估。

Crunchy Data 写了一篇整数溢出的复盘：用 serial 或 int4 做主键的系统，在增长几年后会突然撞上序列上限，一旦触发就直接阻断写入。这类问题的特点是长期无声、爆发突然，靠事后处理代价很高。可行的做法是把序列余量纳入例行巡检，检查 int4 主键与对应序列的当前值和最大值，提前排期迁移到 bigint；迁移本身要评估锁的持有时间、索引重建、外键约束以及应用侧的类型边界。

npm 生态又一次出现供应链攻击，被称作 IronWorm 的恶意代码波及 36 个包；同期还出现了针对 .github/setup.js 的供应链告警。前端依赖树庞大，包维护者账号、发布权限、传递依赖、锁文件和 CI 构建都是攻击面。团队应尽快复核锁文件与最近发布的版本，跑一遍依赖审计，收紧 CI 令牌权限，检查包的来源证明与可信发布配置，并为生产项目保留物料清单和可回滚的构建产物。

CPython 的 JIT 已经在主仓库里以实验形式存在了一段时间。指导委员会发公告要求补齐正式决策：走 PEP 流程说明目标、维护承诺和取舍，否则就把它移出主仓库。公告不是否定 JIT，而是把一个影响运行时的大改动重新拉回正式流程。JIT 牵动发行版打包、调试器与性能剖析工具、性能承诺和长期维护成本，依赖 Python 性能路线的团队可以跟进 PEP 进展，同时别把主分支上的 JIT 当作稳定的生产承诺。

查询提示在 PostgreSQL 社区争论了二十年，19 的答案是 Robert Haas 写的 pg_plan_advice 和 pg_stash_advice 两个 contrib 模块。提示不写进 SQL：一种是设 pg_plan_advice.advice 这个 GUC 给建议，另一种是把命名的建议集放进共享内存按查询 ID 匹配，可按会话或数据库限定范围。可指定扫描方式、连接顺序、连接方法和并行度，聚合与集合运算仍管不了。

PostgreSQL 19 Beta 1 发布次日，CloudNativePG 就在 postgres-containers 仓库放出 19beta1-minimal-trixie 系列镜像。做法很短：在 Cluster 资源里把 imageName 指向该镜像，设好实例数和存储，部署后用 kubectl exec 执行 select version() 确认版本。项目方明确 Beta 镜像不用于生产，目的是在正式发布前把缺陷试出来。

PostgreSQL 按行存储，一张 15 列的表哪怕只查 2 列，扫描时仍要把匹配行的全部列读进来。文章给的例子是每行只需要 12 字节却读了 200 字节，放大约 16 倍；索引解决不了这件事，因为索引优化的是选哪些行，不是每行读多宽。列式存储按列组织数据，只读需要的列。TigerData 给出的折中是 Hypercore：新数据保持行格式保证写入速度，旧数据转成列格式提升分析扫描效率。

Ayush Tiwari 提议把 contrib 里的 refint 模块在 PostgreSQL 20 中删掉。文档早就写明它的功能已被内置外键取代，最近又接连暴露问题：级联 UPDATE 置空时崩溃、计划缓存损坏，维护成本超过了它作为示例代码的价值。补丁从 contrib/spi 移除相关文件并调整升级测试。Nathan Bossart、Daniel Gustafsson 和 Tom Lane 都赞成移除，建议先在文档里预告。

PostgreSQL 全球开发组发布 19 的第一个 Beta，正式版预计在 2026 年 9 月到 10 月之间。性能侧有异步 I/O 增强、并行 autovacuum 和 worker 自动伸缩，存在外键时插入速度最多提升到两倍。新功能包括 SQL/PGQ 属性图查询、GROUP BY ALL 和增强的时态查询，安全侧加了 SNI 与密码过期警告，监控多了两个统计视图。逻辑复制支持序列复制，数据校验和可在线打开，JIT 默认关闭。

Stefan Fercot 用 pgBackRest 2.58.0 配 Percona Server for PostgreSQL 18 和 pg_tde 做了一轮实测，数据是约 1.5 GB 的加密 pgbench 表，仓库放在 S3 兼容对象存储上，WAL 也开了加密。结论是全量与增量备份、同步和异步归档、恢复到命名还原点都正常，用 OpenBao 管密钥的过程对备份透明。代价是压缩、块级增量、WAL 头校验和页校验都得关掉。

PostgreSQL 一个连接一个后端进程，每个后端空闲时占十几个文件描述符，写入时可能到几百个，max_connections 设得过大又不做池化，很容易撞上 fs.file-max 或进程的 RLIMIT_NOFILE。征兆是日志里先出现 out of file descriptors，随后后端被信号 6 终止并触发崩溃恢复。作者的建议是用 PgBouncer 把连接收敛到几百个后端。

AWS 数据库博客连着发了两篇，梳理 Aurora PostgreSQL 和 RDS for PostgreSQL 上由扩展提供的索引类型：一篇讲 bloom、pg_trgm 和 pg_bigm，覆盖多列等值过滤、模糊匹配与日文等亚洲语言的检索；另一篇讲 SP-GiST、btree_gin 和 btree_gist，落点在操作符类和可扩展索引框架。这些能力在生产里常见却容易被忽略，适合拿来做索引设计评审。

跨区域容灾最难的部分往往不是复制本身，而是切换时的容量、顺序、依赖服务、入口和回退。AWS 的应用恢复控制器给 Region switch 增加了 Amazon Aurora 的扩容和 Amazon Neptune 全球数据库的故障转移，让数据库恢复并进统一的应用恢复计划，跨区域恢复从手写 runbook 往托管控制面走。用这套方案前仍要实测演练：读写角色切换、容量预热、依赖顺序、RTO 与 RPO，以及失败后的回滚路径。

Web PKI 是互联网安全的公共底座，后量子迁移不是换一张证书那么简单，会牵动浏览器、CA、TLS 握手、证书链长度和运维自动化。Let's Encrypt 公布了自己的后量子路线，把 Merkle Tree Certificates 列为可能方向，目标是在量子威胁到来之前给出可部署、可扩展且不明显牺牲 TLS 性能的方案。平台团队可以开始跟踪 ACME 客户端、证书链大小和内部 CA 会受哪些影响。