PostgreSQL 博览 2026-06-12 RSS 订阅

AWS 宣布 Aurora PostgreSQL 支持 18.3，覆盖所有商用区域和 GovCloud，可以通过蓝绿部署、原地升级或快照恢复三条路径升级。云上托管的 PostgreSQL 由此进入 18.x 的迁移周期。对生产环境来说，升级时保留统计信息和逻辑复制方面的改进，比单个 SQL 特性更值得关注，它们直接影响升级后的查询稳定性、复制延迟和可用的迁移窗口。迁移测试应重点看执行计划稳定性、跳跃扫描的命中情况和扩展可用性。

在没装 psql 的机器上执行 neonctl psql 会直接报找不到命令，而大多数 macOS 笔记本、精简的 Linux 容器、Windows、CI 运行器和沙箱环境都属于这一类。Neon 因此用纯 TypeScript 重新实现了 psql 客户端，并把它直接嵌进 neonctl。为了确认这份实现与原版行为一致，团队搭了一套逐字节比对的一致性测试框架，直接用 PostgreSQL 自己的回归测试套件来验证输出是否完全对得上。

Tiger Data 的这篇文章讨论 PostgreSQL 会失手的场景。作者的判断是它能覆盖九成负载，剩下一成集中在高频只追加写入、持续写入压力和分析型查询：当数百万行只写一次、从不更新时，MVCC 的开销就变成了负担。文章把加索引、分区和升级硬件称作优化跑步机，能缓解一时却解决不了架构错配。识别的办法是用诊断查询看表的更新占比和自动清理频率，这类负载改用 hypertable 与列式存储可能比继续调优更合适。

开发者机器是供应链攻击最现实的入口之一，而 Homebrew 的 tap 本质上可以执行 Ruby 代码，此前这条信任边界是隐式的。6.0.0 把它变成需要显式确认的动作，同时修复了一批安全问题：下载策略中 HTTPS 到 HTTP 的重定向保护被绕过、macOS pkg 安装后脚本以 root 执行代码、用户可控的 /var/tmp plist 属主。团队应检查内部 Brewfile、私有 tap 和 CI 里的安装行为。

Obsidian Security 披露了 LiteLLM 的一条漏洞链，从权限提升一路走到远程代码执行，并演示了被控制的网关如何向下游 agent 注入任意工具调用，把执行路径扩大到 agent 运行时。研究者建议升级到 v1.83.14-stable 或更高版本，并审计 proxy_admin、guardrails、callbacks、供应商密钥和 MCP 令牌。这类网关能看到提示词、响应、工具定义和凭据，应按高敏感基础设施治理。