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