PostgreSQL 博览 2026-06-06 RSS 订阅

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 当作稳定的生产承诺。