Aurora PostgreSQL 18.3 正式可用
AWS 宣布 Aurora PostgreSQL 支持 18.3,覆盖所有商用区域和 GovCloud,可以通过蓝绿部署、原地升级或快照恢复三条路径升级。云上托管的 PostgreSQL 由此进入 18.x 的迁移周期。对生产环境来说,升级时保留统计信息和逻辑复制方面的改进,比单个 SQL 特性更值得关注,它们直接影响升级后的查询稳定性、复制延迟和可用的迁移窗口。迁移测试应重点看执行计划稳定性、跳跃扫描的命中情况和扩展可用性。
保留原始来源与发布日期的新闻、博客和活动。
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 令牌。这类网关能看到提示词、响应、工具定义和凭据,应按高敏感基础设施治理。
代码已开源,示例覆盖 LangGraph 行程助手,产物包含分类体系、测试集、轨迹、评分与指标。
GitHub 称它不依赖代码扫描、Dependabot 或密钥扫描,是按需的轻量补充,不能替代 CI 里的安全扫描。