PG Summit 2026 演讲：Postgres 硬件基准测试

Richard Yen 将在 10 月 1 日的 PG Summit 2026 上分享用 Postgres 做硬件基准测试的经验，并提前聊了聊选题动机。

想测磁盘速度用 fio，想测 CPU 单项操作也有更合适的工具，这些组件级测试能说明单个部件的情况。但 Postgres 基准测试的目标不是复现产品页上的营销数字——比如三星 EVO Plus 990 标称读写 7,150/6,300MB/s，但正经的 Postgres 集群很难跑到这个值。

Postgres 是包含内存、并发、缓存、WAL、检查点、后台进程和多种维护机制的复杂系统，这些可能同时发生。跑十秒的基准可能只测到系统里又热又快的一小片，却漏掉了生产环境真正值得关注的部分。有经验的 DBA 或 DBRE 知道 autovacuum 会在负载运行时产生额外工作，检查点会带来 I/O 突发，高并发负载可能在存储设备忙起来之前就撞上锁竞争或连接数上限，缓存状态也会改变问题本身。

所以该问的问题不是「这块 SSD 多快」，而是「这个工作负载在这套系统上能否跑得可接受，系统还能承受多少」。定义工作负载是基准测试的第一步：是大量小并发事务的 OLTP，还是大扫描大 join 的分析型负载，或是宽 JSON 文档、可压缩值、高写入量的场景。确定负载后，在受控步骤中调参并监控不同指标，当吞吐停止增长、延迟超标或某资源饱和时，就能更清楚数据库整体的能力边界，第一个瓶颈也指明了下一步方向。

可信的基准要跑足够久以覆盖几个 autovacuum 和检查点周期，并且可重复。应记录配置、数据集、客户端位置、预热期、测量窗口和验收标准，还要测试系统过载后能否恢复。严格的硬件基准测试仍有其位置，但应单独做——fio 适合回答存储性能问题，Postgres 基准测试的目标是理解特定数据库负载能否跑在特定系统上、在哪里停止扩展、先遇到哪个约束。

演讲将深入这套流程，涉及 HammerDB、pgbench、工作负载设计，以及帮助定位真正瓶颈的证据。

🔗 原文：postgr.es/p/9uu

触发自主代理的最佳方式：从诊断而非警报

在 Anthropic 的 AI‑Native SDLC Playbook 中，Stage 6（维护）通过脚本监控生产指标，当控制带被突破时启动 Claude 会话。传统做法是先检测异常，再让代理自行推断根因，导致代理在最昂贵的阶段花费大量 token 进行排查。Causely 通过先生成诊断（Issue）并携带因果链，直接把诊断作为触发点，让代理从根因开始行动，省去多余的推理步骤。

- 控制带：脚本基于滚动基线和 Western Electric 规则设定 1σ、2σ、3σ 阈值，分别记录、只读诊断、或直接打开 PR。
- 诊断触发：Causely Issue 包含受影响实体、主诊断和证据链，代理收到后立即获取诊断细节，直接定位根因。
- 自动修复：代理读取代码、编辑、提交并打开 PR，所有操作在仓库内完成，避免再次访问监控系统。
- 成本与噪声控制：只对 Critical/High 严重度 Issue 触发，避免无效循环。

示例流程
1. 监控脚本检测到外部支付 API 超时，生成 Severity Critical 的 Issue。
2. 接收器将 Issue 转为代理首条消息，代理调用 get_issue_details 获得因果链。
3. 代理定位 payment-adapter 的慢调用，编辑 main.go 添加断路器和超时，提交 PR。
4. PR 说明根因与修复，审核后合并。整个过程从 Issue 到 PR 仅耗 4 min 54 s，诊断时间 17 s。

如何实现
- 在外部系统中部署一个 FastAPI 接收器，将 Issue 事件转为代理会话。
- 仅发送 Critical/High 级别的 Issue，避免触发无效循环。
- 通过 PR 审核确保诊断正确，分支保护防止代理自行合并。

下一步
克隆示例仓库，使用本地 kind 集群观察从 Issue 到 PR 的完整流程。随后可对比有无因果上下文的多种场景，评估 token 消耗与诊断时间。

🔗 原文：点击查看

Grafana Cloud 数字体验监控更新

生产环境出问题时，仅靠指标很难回答几个关键问题：谁受影响、用户实际看到了什么、是否值得叫醒值班人员。Grafana Cloud 的 Digital Experience Monitoring（DEM）把 Frontend Observability 与 Synthetic Monitoring 结合起来，用真实用户体验数据配合主动测试，帮助团队判断问题影响范围、定位原因并更快恢复。

核心能力包括四块：真实用户可见性，了解用户实际体验而非只看后端指标；主动检测，对关键用户旅程跑自动化检查，赶在用户之前发现问题；端到端关联，把前端信号与背后的后端 trace 连起来；更快恢复，把平均恢复时间从小时级压缩到分钟级。

Session Replay 由 Grafana 开源 JavaScript 埋点库 Faro 驱动，可回放用户在 Web 应用中的操作，并与 Core Web Vitals、用户行为、trace 等真实用户监控信号关联。配置时在 Faro 初始化里加上 ReplayInstrumentation 即可，默认隐私优先，可调整掩码、隐私和采样选项，比如只录制一定比例的会话。

回放播放器支持播放、暂停、前后跳 10 秒，速度从 0.25x 到 16x 可调，可跳过空闲片段，还能复制特定时刻的分享链接。侧边栏展示带时间戳的用户旅程，可查看错误、直接跳转并筛选排序。由于回放与 Faro 遥测数据关联，可以从仪表盘上的前端错误直接跳进对应会话的回放，看用户出错时的操作，再深入关联的 trace。

Synthetic Monitoring 与 Frontend Observability 的集成也有更新。每次 Synthetic Monitoring 浏览器检查运行时会自动创建一个对应的 Frontend Observability 会话，这是一个完全可控、可重复的真实用户旅程。从检查内部可直接拉取 Frontend Observability 数据，跳进该次运行创建的会话，查看会话回放、用户旅程和 trace。合成检查不再只是通过或失败，每次运行都有反馈，失败时能看清具体发生了什么，回答值班工程师最关心的问题：这个失败检查是否影响真实用户、影响了多少人。

从告警到失败执行再到回放，现在只需几次点击就能完成排查。Grafana Cloud 免费层包含每月 10 万次测试执行。

🔗 原文：点击查看

Kubernetes v1.37：Memory QoS 进入 Beta 并默认开启

Kubernetes 1.37 将 Memory QoS 升级为 Beta，并在所有节点上默认启用。该功能利用 cgroup v2 的内存控制器，为内核提供更精准的容器内存管理指引。默认情况下，kubelet 不会写入 memory.high、memory.min 或 memory.low，除非你显式配置。

如何开启或配置

- 开启内存限速
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
```
该值在 0–1 之间，用于计算 Burstable 与 BestEffort 容器的 memory.high。

- 开启分层内存保护
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryReservationPolicy: TieredReservation
```

- 同时开启限速与分层保护
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
memoryThrottlingFactor: 0.9
memoryReservationPolicy: TieredReservation
```

- 完全禁用
```yaml
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
featureGates:
MemoryQoS: false
```

已知限制

- 分层保护是节点级别的，所有 pod 共享同一策略；无法单独为某些 pod 开关。
- 采用硬性保留时，容器的 page cache 也会被计入，可能导致大文件读取占用过多内存。

后续计划

Memory QoS 将继续收集 Beta 期反馈，随后推进至 GA。若遇到问题，请在 kubernetes/kubernetes 提交 issue。

🔗 原文：点击查看

Cursor 推出代码托管服务 Origin

Cursor 于 2026 年 8 月 17 日发布 Origin 早期测试版，这是一套内置于 Cursor 应用的 Git 兼容代码托管服务，支持仓库、Pull Request、代码浏览，并与 GitHub 双向实时同步。Origin 面向所有付费 Cursor 套餐（Pro、Teams、Enterprise）分阶段开放，无免费层。上线当天恰逢 GitHub 全球性宕机约 8 小时。

Origin 的入口是新增的 Codebase 标签页。用户可直接在 Cursor 内创建仓库、推送代码、发起和审查 PR、浏览与搜索代码库，无需离开应用。仓库与普通 Git 仓库行为一致，可本地 clone、添加 Origin 为 remote 并从命令行推送。

Origin 支持两类仓库并存：在 Cursor 内创建并托管于其基础设施的 Origin 仓库，以及连接 GitHub 账号后拉入的 GitHub 同步仓库。同步仓库实时更新，推送仍走 GitHub，GitHub 保持为同步仓库的事实来源；PR 与评论双向同步，可随时断开同步。

与 GitHub 同步的仓库中，Cursor 的 agent 可直接回答关于所浏览代码的问题、做出修改、更新 PR 或推送分支，无需本地 clone。官方称更深层的 agent 原生能力（理解 agent 编写代码的工具、自动将 PR 推向可合并状态的自动化）即将推出。

启动时已接入 Vercel、Depot 与 Buildkite：每个 PR 可获得 Vercel 预览部署，Depot 与 Buildkite 可运行现有 GitHub Actions 工作流，Buildkite 还支持其原生流水线。

本次发布也是 Cursor 作为 SpaceX 全资子公司后的首个产品。据 The New Stack 报道，SpaceX 对 Cursor 的收购（报道称 600 亿美元）于 2026 年 8 月 14 日正式完成，三天后 Origin 上线。

Origin 工程师 Tomas Reimers 在 Hacker News 上承认，当前托管功能与 GitHub 差异「非常小」，团队有意在功能上正面竞争；真正的差异点在于仓库、PR 与 coding agent 同处一个产品。若你已在付费使用 Cursor，开启 GitHub 同步无需额外成本，即可让 agent 进入 PR 工作流；但现阶段仍不宜将其作为关键生产仓库的主托管，agent 原生能力尚在路线图上。

🔗 原文：点击查看

AI Agent 失败根源在上下文缺失

2026 年构建一个可用的 AI Agent 已接近解决：持久状态、沙箱执行、可观测性都成了平台原语，不再是耗时数季度的工程。真正让 Agent 在生产环境翻车的不是模型，也不是脚手架，而是缺失的上下文——代码和工单之外的那些决策、讨论与团队隐性知识。解决办法是构建一个专门的上下文层。

基础设施已被 Cloudflare Agents SDK、Vercel AI SDK、Mastra 等平台和框架商品化。如今定义一个 Agent 基本只剩四个决定：用哪个模型、什么指令、哪些工具、代码跑在哪。

Agent 失败是因为它基于组织的不完整图景做推理。典型场景：Agent 被要求排查 QA 流水线性能回退，它查了工单和代码，自信地建议重新启用异步分发——但几天前正是这个改动导致过宕机，工程师特意禁用了它。这个决定只存在于 Slack 线程和事后复盘工单里，Agent 读的代码中根本看不到。

2026 年 7 月提交的 arXiv:2607.14275 论文系统验证了这一点：可测量的上下文属性直接预测失败模式——grounding sufficiency 预测幻觉抵抗，guardrail coverage 预测操纵抵抗，instruction consistency 预测指令遵循，tool-schema quality 预测工具调用正确性。Agent 不是单独失败的，是它的上下文先失败了。

MCP 解决的是访问问题，不是理解问题。原始连接器输出会淹没上下文窗口、把冲突裁决推给模型。上下文层位于 MCP 连接的源与 Agent 之间，做检索、调和、排序和权限限定，让 Agent 基于经过核验的摘要推理，而不是面对数据洪流。

落地五步：先加追踪，完整读取 Agent 运行轨迹；盘点组织里决策实际存放的位置；通过 MCP 或直连接入可搜索存储；在检索前定义冲突规则（时效、来源权威性、人工覆盖）；按任务返回排序、权限校验、综合后的摘要，并用论文中的四个上下文质量属性做发布前检查。

如果你在 2026 年构建真实业务 Agent，稀缺资源不再是脚手架，而是组织上下文。把省下的基础设施时间花在审计 Agent 能看到什么上，把每次「自信地错」当作上下文 bug 而非模型 bug。先看追踪，连接孤岛知识，集中调和，交付摘要而非数据洪流。

🔗 原文：点击查看

Auterix：让AI编码助手守住架构约束

用 Cursor、Claude Code 或 Copilot 改代码时，会话超过十几轮后，模型常会忘记你开头定下的架构约束——覆盖核心工具文件、重复实现已有函数、改 A 文件不管 B/C/D 是否被破坏。作者认为问题不在模型能力，而在上下文没有被当作协议契约对待，于是开源了 Auterix 来强制 AI 在执行前先验证上下文。

会话上下文窗口有限，5–10 轮后早期约束会被新信息挤掉优先级。单文件修改没问题，多文件改动就暴露弱点：助手忘记代码库的特定错误处理模式、不知道某个工具已存在而重复实现、套用与自定义配置冲突的框架约定。

作者在 Next.js 项目里同时用 Claude Code、Cursor 和 GitHub Copilot，三者的规则文件各不相同（.cursorrules、CLAUDE.md、.github/copilot-instructions.md），中途切换工具时新助手对项目的理解不一致，一周内出现静默回归、重复解释架构决策、代码评审兜底本应前置拦截的漂移。

Auterix 强制四阶段工作流：先让助手说明要改什么、为什么，重读代码库相关部分并核对规则文件；再生成明确的 diff 展示改动范围；你确认后它才动文件；执行后跑测试、检查级联失败并回报。把「希望助手记得约束」变成「助手证明它理解了约束」。

工具还提供 npx auterix doctor 诊断，检查各工具配置是否同步、Git hooks 是否就位、规则文件是否匹配、上下文 SHA-256 哈希是否变化、是否有违反规则的未提交改动等。Web Studio 可在线选技术栈配置规则并导出 .cursorrules，无需安装 CLI。

Auterix 为 MIT 协议开源，纯 Node.js ESM，无运行时依赖，支持同步 21 种 AI 编码工具的规则配置。作者同时在做商业版 Auterix Pro，提供生产蓝图、常见框架预置防护和 CI/CD 集成，核心功能保持开源免费。

GitHub

🔗 原文：点击查看

Postgres 开发活动数据盘点

Postgres 开发者 Tomas Vondra 在博客中发布了一组关于项目开发活动的统计图表，覆盖 pgsql-hackers 邮件列表和 git 仓库两个维度，量化了社区多年来的变化趋势。

邮件列表消息量从早期每天约 25 条增长至目前约 100 条，峰值可达每天 200 条，出现在每年 3 月（下一大版本特性冻结前）。消息总大小在 2009 年前保持平稳，之后约翻倍至每天 200kB，2016 年起逐步增长至约 2MB/天。

附件方面，每条消息的附件大小从约 10kB 增至约 80kB；带附件（很可能为补丁）的消息占比从 2008 年前约 5% 升至约 25%。补丁拆分趋势明显，平均约 1.6 个部分，90% 补丁为单一部分，99% 少于 10 个部分，但存在多达 76 个部分的补丁。

git 提交方面，每周约 50 次提交，2010 年约为每周 25 次，增长与活跃提交者数量同步（同期约增长 2 倍）。提交大小多数时间稳定在每周约 512KB，但每年 5 月会出现约 20MB 的峰值，对应翻译文件更新。1996 至 2026 年间，仓库累计新增约 440 万行（含注释、文档、测试等，非仅代码行）。

这些数据印证了社区规模与开发节奏的持续增长，也反映出补丁提交和讨论方式随 commitfest 机制引入而发生的变化。

🔗 原文：postgr.es/p/9uw

AWS Launch Wizard 简化云部署流程

AWS Launch Wizard 是一项引导式部署服务，帮助用户在 AWS 上部署受支持的应用程序与基础设施。用户通过引导界面填写应用需求，服务即可推荐合适的资源、校验配置、估算成本，并在确认后完成部署，省去手动配置 EC2、VPC、子网、安全组、存储等环节的繁琐工作。

支持的工作负载包括 Microsoft SQL Server、SAP、Microsoft Active Directory、Remote Desktop Gateway，具体可用项取决于 AWS 区域。

工作流程为：填写需求 → 资源推荐 → 配置校验 → 成本估算 → 部署。部署过程使用 AWS CloudFormation 完成资源编排，生成的模板可复用，便于在开发、测试、生产环境建立一致的基础设施基线。

关键能力包括：根据 CPU、内存、带宽、存储性能等需求推荐实例类型与 EBS 卷；提供基于按需定价的成本估算，配置变更时同步更新；部署前进行早期校验，提前发现资源配额不足或基础设施不满足前置条件等问题。

适用场景方面，学生团队部署 SQL Server 数据库项目时，可指定 CPU、内存、存储、节点数等需求，由服务推荐基础设施并给出成本估算；企业部署高可用 SQL Server 时，可跨多个可用区配置 Always On 可用性组，提升故障恢复能力。

需要注意：Launch Wizard 本身不额外收费，但生成的资源（EC2、EBS、网络等）会产生 AWS 费用；它简化部署但不替代对 VPC、IAM、EC2 等基础概念的理解；不构成完整的自动扩缩容方案；安全责任仍由用户承担，需自行管理 IAM 权限、安全组与凭据。

对刚接触 AWS 的开发者来说，Launch Wizard 提供了一个观察多个 AWS 服务如何协同组成完整应用环境的实际案例；对需要重复部署相似环境的企业，它也能减少手工配置工作量，让部署过程更可重复、更可控。

🔗 原文：点击查看

PostgreSQL 19 新增计划建议与缓存插件

PostgreSQL 19 引入了 pg_plan_advice 与 pg_stash_advice 两个 contrib 模块，帮助开发者在查询计划变更后快速恢复旧计划。
- pg_plan_advice：可将查询计划导出为文本字符串，并在后续执行时强制使用该计划。
- pg_stash_advice：按查询 ID 存储这些字符串，并在查询执行时自动应用，支持跨会话持久化。

使用方式简洁：
1. 在 postgresql.conf 中分别加入
```conf
session_preload_libraries = 'pg_plan_advice'
shared_preload_libraries = 'pg_stash_advice'
```
2. 对需要固定的查询执行
```sql
EXPLAIN (COSTS OFF, PLAN_ADVICE) SELECT …;
```
结果会在 Generated Plan Advice 块中给出四行建议，描述 join 顺序、join 方法、扫描方式和并行性。
3. 若想自动化恢复旧计划，只需 CREATE EXTENSION pg_stash_advice;，插件会根据查询 ID 自动匹配并强制使用保存的计划。

此功能适用于任何需要在统计变化或版本升级后保持查询性能的场景，尤其在 PostgreSQL 16 与 19 之间进行升级前的计划对比时极为有用。

GitHub: GitHub
GitHub: GitHub

🔗 原文：postgr.es/p/9uC

SetrixDB：Go 编写的精确集合引擎

SetrixDB 是一个可嵌入的 Go 集合引擎，针对 uint64 ID 提供精确的成员判断与集合交集运算，核心思路是把集合当作位图、把交集当作 AND 操作。它面向电商筛选、权限检查、反欺诈、RAG 候选预过滤这类场景，数据本身留在原数据库，SetrixDB 作为索引或预过滤器旁路运行。

项目从零实现了最小完美哈希函数（CHD v2）做键生成，在 5000 万键上零冲突，约 4.03 bits/key，查找约 118 ns。位图 AND 内核通过 cgo 走 AVX-512，带运行时指令检测与标量回退，同一二进制可在任意 CPU 上运行。支持分片与集群模式，节点增删只重映射约 1/(N+1) 的 ID。

实测数据（2 vCPU AMD EPYC Zen4，AVX-512，Go 1.22，2026 年 9 月）：
成员判断（100 万键）：SetrixDB 结构占用 0.5 B/key，约 118 ns/次；Go map 为 22.3 B/key、133.3M ops/s；Bloom filter 1.2 B/key、23.6M ops/s，但有 1% 误报。
交集（A=B=100 万）：AVX-512 位图 AND 6 µs，纯 Go 位图 29 µs，Roaring 148 µs（稠密 ID）/523 ms（随机 64 位 ID），排序归并 9.2 ms，hash join 91.6 ms。
真实数据集验证：Online Retail II 上 "UK AND Q4/2011 AND price ≥ 5" 返回 22,701 行、823 µs；Wikipedia 标题（1926 万条）上 "multi-word AND starts with s" 返回 1,408,399 条、9.5 ms；MovieLens 25M 上三组查询结果均与外部 sort+comm 校验一致。
同一 25M ID 宇宙、千万级集合上，排序列表归并 87.7 MB/80.4 ms，稠密位图（AVX-512）2 MB/227 µs，约快 350 倍、小 43 倍。

作者也明确列出了劣势：宇宙空间稀疏或超出内存时不如 Roaring；不支持范围查询、相似度与 join；MPHF 面向静态集合，频繁增删需要重建。当前为 v0.1.0 alpha，已在回环与双机间测试，3 节点集群在云端跑过但未经历多数据中心生产环境。

项目开源，Apache-2.0 许可，代码与可复现基准见 GitHub：GitHub

🔗 原文：点击查看

Google Doc 导入 Confluence Cloud 实操指南

Confluence Cloud 可以直接导入 Google Doc，无需下载转换再上传。在创建页面时，点 Share 旁的 More actions，选 Templates and import，打开 Import 标签，选 Google Doc 并授权账号，文档就会变成 Confluence 页面。短文档到此就结束了，麻烦出在共享盘、图片和长文档上。

导入入口只在创建页面时出现，编辑已有页面时找不到导入按钮，这是最常见的误解。支持 Word、Google Doc、OneDrive 文档，可一次导入多个文件。Atlassian 明确说明单文件与批量导入的要求不同，且因文档类型而异，迁移前最好用自己的文件测试。

内置导入的优点是直接与 Google 通信，文件不经过本地。正文、列表和多数表格能保留可用状态。但共享盘文档通常选不到，文件在个人 Drive 列表里不出现，Confluence 端没有设置可修复。图片多数正常，偶尔会变成占位符，删除源文件前务必检查导入后的页面。文档标题会成为页面标题，原有标题层级整体上移一级。Word 中的形状会被替换为占位符，图内绘制的图表不会保留。

遇到共享盘文件导入失败，标准绕行方案是在 Google Docs 里下载为 .docx，再通过同一导入入口作为 Word 文档导入，仅接受 .docx 扩展名。这也让你在导入前能编辑文件。

每个文件导入后成为单个页面。几十页的手册会变成一页无限滚动，没有分节导航，目录只是单页上的锚点列表。Data Center 版支持按标题层级拆成多页，Cloud 没有这个选项。手动拆分每节约需 6-8 分钟，25 节的手册约三小时，且下次修订还要重来。

长文档两条路：先在 Word 或 Docs 里按目标页面拆成多个文件再批量导入，繁琐但免费且结果可预期；或使用导入时自动拆分的应用，仅当这种情况频繁发生才值得。导入是一次性转换，之后 Google 与 Confluence 互不同步，需要保持原文档活跃时用 Google Drive 宏嵌入而非导入。PDF 不能作为页面内容导入，只能作为附件挂载。

对会议记录这类短文档，内置导入免费且够用；结构化长文档才需要额外方案。导入前先确认文档类型和规模，避免迁移后才发现问题。

🔗 原文：点击查看